基于SpringBoot+Vue的选课与课程评价整合平台开发实战

做校园系统这块，最常听到的一句话就是"能跑就行"。去年教务处的老师把选课和课程评价两套系统同时丢给我的时候，说了一句让我印象很深的话："能不能让它们变成一个系统？"当时的情况是：学生在选课系统里抢完课，还得记着另一个网址、另一套账密去完成课程评价，不评价就看不到成绩；而评价结果只躺在教务处的Excel里，对下一轮选课毫无参考价值。所以基于SpringBoot+Vue的选课系统与课程评价整合平台，并不是简单的接口对接，而是把业务闭环重新设计了一遍。

这篇文章会完整复盘这个项目的需求拆解、数据库建模、并发选课、评价统计、前端交互和部署细节，包含可以直接参考的表结构、核心代码和踩坑记录。适合正在做教务类系统、选课平台毕业设计，或者想了解SpringBoot+Vue前后端分离项目完整落地过程的读者。我先说清楚：这篇不是论文模板，是我在实际开发里验证过的做法，里面有不少"不这么做就一定会出事"的细节。

1. 项目定位：选课和评价为什么要放进同一个平台

1.1 两套系统割裂带来的真实问题

很多学校的业务系统都是历史包袱叠出来的：选课系统单独部署，课程评价单独部署，甚至教职工考勤又挂一个站点。每个系统各自登录、各自维护，账号体系都不统一。学生这边，选课选得再顺手，学期结束时还是得被赶去另一个系统评教，评完了才有成绩查询权限；教师那边，想看看自己上轮课程的评价反馈，得等教务处手工导出Excel再发下来；教务处这边，评教完成率、选课人数、热门课程分布全要靠人肉汇总。

这种割裂最大的问题不是"使用麻烦"，而是"数据之间没有关系"。选课记录是选课记录，评价结果是评价结果，系统里根本不存在一条链路能回答"这学期哪门课评分高但选课人数少"这种看似简单的问题。做整合平台，核心目标就是把这两块数据放到同一个业务模型里，让评价结果反过来影响下一轮的选课决策。

1.2 整合平台给三类用户带来的可见收益

我从需求调研阶段就按角色拆使用场景，这个习惯帮我少走了很多弯路。

对学生来说，一个入口完成所有事：查课程、看往届评价均分、加入选课单、提交选课、学期末评价，全部在同一个系统里完成。最明显的变化是，选课页面上每门课旁边直接显示近两个学期的综合评分和评价人数，不用再跑到论坛去问"这门课老师给分怎么样"。

对教师来说，开课前就能看到上一轮自己课程的匿名评价摘要，包括各维度均分、被提最多的关键词（比如"作业负担重""案例丰富"），可以针对性地调整教学内容和考核方式。教师端就不用再等教务处发Excel了。

对教务处来说，后台能看到实时选课人数、课程容量利用率、评教完成率、低于平均分的课程预警列表。这些东西原来要靠学期结束时手工统计，现在打开后台就是一张实时仪表盘。

1.3 功能清单与模块边界

需求梳理完，模块边界我画得很清晰：

角色	核心模块	功能点
学生	课程查询、选课、课表、评价	多条件检索、选课单提交、周课表视图、维度打分与评语
教师	开课管理、评价反馈	维护开课信息、查看匿名评价统计、查看评语热词
教务管理员	基础数据、选课阶段、评价管理	用户与角色维护、开课计划审核、选课开关/补选/退选、催评任务、数据导出

边界也很明确：不做培养方案管理、不做成绩录入、不做学生考勤。这些是其它系统的事，硬塞进来只会让项目无限膨胀。整合平台的价值在于打通选课和评价这一段闭环，而不是重新发明教务系统全家桶。这个克制很重要，后面所有设计都围绕这条主线。

2. 技术选型复盘：为什么敲定SpringBoot 3 + Vue 3 + MyBatis-Plus

2.1 后端框架：SpringBoot的自动装配和生态

后端选SpringBoot没什么悬念。SpringBoot最核心的价值就是自动装配：引入一个spring-boot-starter-*依赖，框架自动完成Bean的注册和配置，开发者只需要在application.yml里写业务需要的配置项。比如引入spring-boot-starter-data-redis之后，RedisTemplate直接可用，引入spring-boot-starter-security（或单纯用拦截器）就能做登录校验。对于教务系统这种"业务场景明确、技术栈常规"的项目，SpringBoot能把开发重心从"配置框架"拉回"写业务代码"上。

需要提醒版本选择。SpringBoot 3.x要求JDK 17，如果你所在环境还是JDK 8，稳妥的做法是选SpringBoot 2.7.x。我这次服务器是JDK 17，就用了SpringBoot 3.2，同时MyBatis-Plus选的是3.5.5，因为SpringBoot 3把javax.*迁移到了jakarta.*，老版本的MyBatis-Plus和Swagger依赖会直接编译报错。查兼容矩阵再动手，比踩完坑再返工省时间。

ORM选MyBatis-Plus而不是JPA，主要原因是：教务系统的查询条件组合多（按学院、课程类别、学分段、上课时间筛选），MyBatis-Plus的LambdaQueryWrapper写动态条件很顺手，既有MyBatis的SQL可控性，又有IService这类现成的CRUD基座。分页插件一个PaginationInnerInterceptor就搞定，不比JPA复杂。

2.2 前端框架：Vue 3组合式API更适合复杂选课交互

前端用Vue 3而不是Vue 2，核心原因是组合式API（Composition API）在处理选课流程这种"多状态协同"场景下更好组织代码。