SpringBoot+Vue3奖学金评定系统开发实战：从业务拆解到部署上线

从决定做陕西理工大学奖学金评定管理系统的那一刻起，我就在想，这套系统真正要解决的到底是一个技术问题，还是一个流程问题。后来做完整套前后端分离的项目——后端 Java SpringBoot + MyBatis，前端 Vue3 + Vite，数据库用 MySQL——我才敢说，它本质上是把一套“凭感觉打分、靠Excel催材料”的线下流程，变成了一条可追溯、可配置、可审计的线上链路。这套系统做下来，踩了不少坑，也整理出了一个比较完整的源码结构。这篇东西不是给平台交差，是想把从业务拆解到技术落地的整套思路都摊开讲清楚。

如果你也正在做类似的奖学金管理系统、评审系统、评分系统，或者打算用 SpringBoot + Vue3 这套技术栈做一个前后端分离的项目，下文这些从需求分析到部署上线的细节，大概率能帮你少走一段弯路。

1. 奖学金评定业务的真实痛点与系统边界

1.1 手工评定的三大痛点

做这个系统之前，院里评定奖学金靠的是辅导员发Excel通知，学生提交纸质材料，然后几位老师用共享表格手动统计分数。这套流程有三个特别明显的痛点：

第一个是数据分散。学生的成绩分布在教务系统里，竞赛获奖信息在辅导员手里，德育加分又散落在各种社团评比记录里。每次评定，光汇总信息就要两三天，而且各班级交上来的表格格式五花八门，有的用学号，有的用姓名，有的干脆直接截图。

第二个是规则口径不统一。同一个学院不同专业，加分项可能完全不同。比如计算机专业的学科竞赛加分比例高，文科专业更看重社会实践。但大家用的还是同一张打分表，导致很多加分项只能靠人眼判断，“这个奖能不能加，加多少分”，全凭老师主观决策。这种争议在公示阶段很容易被闹大。

第三个是公示和申诉过程难以留痕。名单公示基本靠打印贴在公告栏，学生有异议就发邮件或者当面找老师。问题在于，最后决定改了谁、为什么改，没有统一的记录。系统正是为了补齐这些缺失的环节而设计的。

我梳理后把系统边界定成这样：不直接对接高校教务系统，而是提供标准化的成绩导入模板和竞赛获奖导入模板；评定流程上做到“学生在线申请—辅导员初核—院系复核—学生处终审—公示发布”这一条完整链路；所有审核意见和得分明细都留痕。

1.2 系统角色与权限闭环

这套系统的用户角色分成四类：学生、辅导员、院系管理员、学生处管理员。系统管理员单独放在后台维护用户和字典。

这里采用了基于 RBAC 的权限设计。如果没有提前规划权限模型，后面一加接口就非常痛苦。我建立的角色权限关系如下：

角色	核心权限	边界
学生	查看奖学金类型、发起申请、填报分数、上传材料、查看公示结果	不能查看他人申请，不能审核
辅导员	初审本班学生申请，退回或通过	只能看自己负责的学生，看不到全学院
院系管理员	配置评分项权重、复核名单、导出本学院报表	不能跨院操作，不能终审
学生处管理员	创建评定批次、终审名单、发布公示、查看全校数据	不能修改学生基础材料

权限这部分用一张 user_role 表和 role_menu 表来实现，前端拿到用户对应的菜单列表，再动态生成路由。这块后面在讲 Vue3 动态路由的时候会详细展开。

1.3 功能模块梳理

按业务链路，系统最后落地成这几个模块：

• 基础数据：学生信息管理、班级专业维护、成绩导入、获奖材料管理。
• 奖学金配置：奖学金类型设置、评定批次管理、评分项与权重设置。
• 申请与审核：学生在线填报、辅导员初审、多级审核流转、材料附件上传。
• 公示与反馈：公示列表、公示详情、意见反馈。
• 系统管理：用户管理、角色管理、菜单管理、操作日志、数据字典。

模块不需要多，但要保证每个模块的字段和状态机跟业务对得上。一个经常被忽略的点是：评定批次必须有状态字段，比如“草稿、进行中、已结束、已公示”。否则学生在非申请期也能提交申请，后边审核逻辑就全乱了。

2. 技术选型为何锁定 SpringBoot + Vue3 + MyBatis + MySQL

2.1 前后端分离的收益

项目采用前后端分离，不是跟风，是从实际开发节奏出发的。前端和后端可以并行开发，定义好接口文档，我一边写后端 CRUD，另一头同事就能用 Mock 数据先做页面。更重要的是，奖学金评定系统需要长期维护，前端页面改动频率远高于后端逻辑，分离之后不至于改个表单样式就要重启整个应用。

分离带来的问题也同时出现了：跨域、Token 鉴权、接口联调成本。这些问题后面在“联调部署的坑”章节里都有对应的处理方案，提前说一句，跨域别一上来就前端代理，先想清楚部署环境。

2.2 Vue3 相比 Vue2 的核心优势

选 Vue3 而不是 Vue2，主要看中三件事。

第一是 Vite 的开发体验确实快，热更新秒开，不用像 Webpack 那样等十几秒。特别是 Vue3 的