Spring Boot高校学生评教系统：从权限控制到防重复提交的全栈实践

毕业设计做了一套Spring Boot高校学生评教系统，源码编号01091，正好赶上期末，很多同学在后台问我要这套系统的设计思路和核心代码讲解。连着解答了十几个问题之后，我发现大家卡住的点其实都差不多，集中在权限设计、评教防重复提交、还有统计报表那几块。干脆把整个项目的完整拆解写成一篇长文，从数据库设计到核心功能实现，再到最后的踩坑记录，一次性说透。这套系统麻雀虽小五脏俱全，角色权限、业务流程、数据统计全都有，作为Spring Boot入门到进阶的练手项目非常合适。

1. 评教系统需求拆解：它到底解决了什么问题

1.1 业务场景与痛点分析

高校里的学生评教，说白了就是每学期末让学生给任课老师打分，从教学态度、讲课水平、作业批改这些维度做评价。早些年很多学校还在用纸质问卷，学生填完一叠表格，教务处的人手工录入统计，工作量巨大还容易出错。后来改用传统的单体JSP系统，又面临维护困难、扩展性差的问题。

这套基于Spring Boot的评教系统，核心就是要解决三个痛点：评教流程线上化、评教结果可量化、角色权限清晰化。学生在网页端勾选打分提交，系统自动汇总核算，管理员能导出报表查看每个老师的得分和排名。整个过程透明高效，也方便追溯。

1.2 三种核心角色与权限边界

系统涉及学生、教师、管理员三个角色，三者不是简单的"能登录"和"不能登录"的区别，而是各有各的操作边界：

• 学生：查看自己本学期需要评价的课程列表，逐门填写评价指标，提交后不可修改，只能查看自己的提交记录。
• 教师：只能查看自己被评价的结果统计，包括平均分、各项指标得分、参与评价人数，看不到具体是哪个学生打的分数。
• 管理员：拥有全部权限，负责维护基础数据（学生、教师、课程）、配置评价指标、发起评教批次、查看和导出汇总报表。

权限这块我建议用角色标识加拦截器的方式，不一定要上Spring Security全家桶。毕设阶段把拦截器写好，路径匹配做严格，完全够用，而且代码更容易看懂。

1.3 业务流程闭环图（文字版）

整个评教流程是这样的：管理员登录后台，先维护好学生、教师、课程数据，然后把教师和课程关联生成开课记录，再创建评教批次并关联开课记录。学生登录后看到待评课程，点进去逐项打分提交。教师和管理员在各自的视角查看统计结果。

这个流程的关键在于"批"的概念。同一门课可能在不同学期开了很多次，一次评教只针对某一个批次，批次不同评价指标可能也不一样。刚开始建模的时候如果忽略批次，直接拿课程做关联，后面扩展性会很差。我第一版就是没加批次表，结果想搞"上学期评价"和"下学期评价"对比时彻底傻眼，后续重构花了不少功夫。

2. 技术选型与项目结构：这套组合为什么好用

2.1 Spring Boot为什么是毕设首选

Spring Boot在这几年几乎成了Java后端项目的默认起点，原因很直白：起步依赖帮我们把版本问题解决了，以前SSH时代各种jar包冲突、版本不兼容的破事全被挡在外面；自动配置帮我们把大部分样板代码省掉了，写一个接口只需要关注业务逻辑本身；内嵌Tomcat让部署变得极其简单，一个jar包直接扔服务器就能跑。

这套评教系统用的具体版本是Spring Boot 2.7.x，对应Java 8。选这个版本没别的原因，就是稳定且资料多。网上问"Spring Boot版本太高"的人很多，实际上3.x的坑不少，比如javax包名改成jakarta、Java 17起步等，毕设阶段没必要给自己加戏。2.7.x完全够用，遇到问题随便一搜就有答案。

2.2 持久层框架：MyBatis Plus确实省事

持久层用的MyBatis Plus，这个选择非常务实。它本质上就是MyBatis的增强工具，单表CRUD不需要写SQL，继承BaseMapper就有一堆现成方法。最爽的是分页，一个PaginationInnerInterceptor配置搞定，不用自己写limit那一套。

比如评教结果的分页查询，如果只查单表，ServiceImpl里直接调用page方法就行；需要多表关联时再在Mapper里写XML的SQL。MyBatis Plus这种"简单操作零SQL，复杂操作写XML"的模式，对毕设来说简直完美。唯一要注意的是字段自动填充，比如create_time这种字段，不配置MetaObjectHandler的话要自己set，否则插进去就是null。

2.3 前端方案与工程目录核心结构

前端我用的是Thymeleaf模板引擎加AdminLTE这套免费后台模板。为什么不用前后端分离？因为毕设周期有限，前后端分离意味着要维护两套工程、处理跨域、写接口文档，时间成本直接翻倍。Thymeleaf直接在HTML里渲染，服务端渲染天然没有跨域问题，一整套下来省心太多。

工程目录按标准三层结构分包：

com.example.evaluation ├── controller # 控制器层 ├── service # 业务逻辑接口 │ └── impl # 业务逻辑实现 ├── mapper # MyBatis Plus数据访问层 ├── entity # 数据库实体类 ├── config # 配置类（拦截器、MyBatis Plus） ├── common # 通用工具（返回值封装、异常处理） ├── interceptor # 登录拦截器 └── vo # 视图对象（多表查询返回用）

很多人写Java毕设喜欢全堆在controller包一个类里搞定，这在应付检查的时候确实爽，但一旦项目稍微复杂一点，几百行的类改起来能让人崩溃。分层的核心价值不是"显得专业"，而是出了问题知道去哪找。

3. 数据库设计：评教系统的地基怎么打

3.1 核心表结构一览

这套系统的表设计是这个项目最值得精读的部分，一共八张核心表。我先用表格把每张表的职责列出来，再逐个拆关键字段：

看着表不少，但业务关系很清晰。核心是evaluation_result，每行代表一个学生针对某一个开课记录在某一个指标上的打分。比如一个批次有5个指标，一个学生评一门课就会插入5条result记录。

3.2 用户与角色的关联设计

这里有个容易纠结的点：sys_user和student、teacher到底什么关系？我采用的是"中间关联"方案，sys_user表里加一个user_type字段区分角色，再用relation_id关联对应的学生或教师主键。学生登录时，先查sys_user定位账号角色，拿到relation_id再去查学生表补充信息。

这种设计的好处是登录认证和业务数据解耦。sys_user只管账号密码和角色，学生表只管学号班级专业。后面如果你要加"辅导员"角色，只需要在sys_user里加一个角色值，再建一张辅导员的业务表就完事了，完全不用动旧的表结构。

密码字段必须加密存储，用MD5加盐或者BCrypt都行。我推荐BCrypt，Spring Security里自带的那套，比MD5安全一个量级，而且本身就是为密码校验设计的，不用自己处理盐值逻辑。就算被拖库，拿到也是不可逆的密文。

3.3 评教防重复提交的数据库设计

评教系统最核心的业务规则是：一个学生在一个批次里对同一门课只能提交一次评价。这个规则必须在数据库层面兜底，光靠业务代码判断不够，因为并发请求下可能同时通过检查，导致插入两条记录。

防重复的数据库设计有两个关键动作。第一，evaluation_submit表上建唯一索引，组合字段是(task_id, student_id, teach_info_id)，这样数据库层面就拒绝了重复提交；第二，evaluation_result表不需要单独做唯一约束，因为它是以submit_id作为逻辑外键的，每次插入都跟着提交记录走，只要submit能防住，result自然安全。

很多教材里讲防重复都是"先查再插"，但实际在高并发下先查再插是有时间窗口的。唯一索引才是真正的兜底方案，业务代码里的判断只是让报错更友好。这也是我推荐在毕设答辩时能讲清楚的一个亮点。

4. 核心功能实现：从登录鉴权到评教打分

4.1 登录认证与拦截器设计

登录这块我用的Session方案，核心逻辑很简单：用户提交账号密码，后端校验BCrypt密文，校验通过后把用户信息塞进Session，同时把用户ID和角色放进去。后续请求通过拦截器判断Session里有没有用户，没有就重定向到登录页。

拦截器是三个角色共享一套，但是在路径匹配上做区分。以/admin/**开头必须管理员角色，以/teacher/**开头必须教师角色，学生端路径发给教师也能访问的话就会拦截。具体实现是重写HandlerInterceptor的preHandle方法：

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); UserVO user = (UserVO) session.getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } String uri = request.getRequestURI(); if (uri.startsWith("/admin") && !"ADMIN".equals(user.getRole())) { response.setStatus(403); return false; } if (uri.startsWith("/teacher") && !"TEACHER".equals(user.getRole())) { response.setStatus(403); return false; } return true; } }

拦截器注册在WebMvcConfigurer里，通过InterceptorRegistry添加并配置拦截路径。这里有个经验之谈，static目录下的静态资源必须排除掉，否则CSS和JS都被拦了，页面整体都是裸的。

4.2 评价指标与打分逻辑详解

评价指标表的设计要能支持"多批次不同指标"。我用的方案是指标表里带一个status字段，0表示停用，1表示启用。管理员配置的时候可以勾选一批指标关联到当前批次，但指标本身的权重、排序全局共享。大多数毕设场景下指标不会频繁变，这个设计已经足够。

打分方式我采用的是最简单的1到5分制，每个指标一个分数。综合得分的计算逻辑是这样的：每个指标设置权重占比，总权重100%。比如教学态度权重20%，讲课水平权重30%，互动氛围权重20%，作业批改权重15%，课程收获权重15%。那么综合得分就是各项分数乘以权重后累加。

// 核心计算逻辑，参数为某个教师某门课的所有评价明细 public BigDecimal calcComprehensiveScore(List<EvaluationResult> results) { // 按指标ID分组 Map<Integer, DoubleSummaryStatistics> statMap = results.stream() .collect(Collectors.groupingBy(EvaluationResult::getIndicatorId, Collectors.summarizingDouble(EvaluationResult::getScore))); BigDecimal total = BigDecimal.ZERO; for (Map.Entry<Integer, DoubleSummaryStatistics> entry : statMap.entrySet()) { double avgScore = entry.getValue().getAverage(); // 查询指标权重 EvaluationIndicator indicator = indicatorMapper.selectById(entry.getKey()); BigDecimal weight = indicator.getWeight().divide(new BigDecimal(100), 4, RoundingMode.HALF_UP); total = total.add(BigDecimal.valueOf(avgScore).multiply(weight)); } return total.setScale(2, RoundingMode.HALF_UP); }

这里用BigDecimal是有讲究的，double直接算加权平均会出现0.1 + 0.2不等于0.3的经典问题。虽然业务上差一点看不出来，但统计报表里对不上账就尴尬了。金额、分数这类数据一律用BigDecimal，这是我踩过的坑，也是答辩时能加分的细节。

4.3 提交评教的Service事务控制

提交评教是整个系统里事务最长的方法，它要干的事情很多：校验批次是否在有效期内、校验是否重复提交、插入提交记录、批量插入评分明细。任何一个环节失败都不能留下半截数据，必须加@Transactional。

@Transactional(rollbackFor = Exception.class) public JSONResult submitEvaluation(SubmitRequest request, Student student) { // 1. 校验批次状态 EvaluationTask task = taskMapper.selectById(request.getTaskId()); if (task == null || task.getStatus() != 1) { return JSONResult.error("评教批次不存在或未开启"); } Date now = new Date(); if (now.before(task.getStartTime()) || now.after(task.getEndTime())) { return JSONResult.error("不在评教时间段内"); } // 2. 校验是否已提交 Long count = submitMapper.selectCount(new LambdaQueryWrapper<EvaluationSubmit>() .eq(EvaluationSubmit::getTaskId, request.getTaskId()) .eq(EvaluationSubmit::getStudentId, student.getId()) .eq(EvaluationSubmit::getTeachInfoId, request.getTeachInfoId())); if (count > 0) { return JSONResult.error("您已完成该课程的评价"); } // 3. 插入提交记录 EvaluationSubmit submit = new EvaluationSubmit(); submit.setTaskId(request.getTaskId()); submit.setStudentId(student.getId()); submit.setTeachInfoId(request.getTeachInfoId()); submit.setSubmitTime(now); submitMapper.insert(submit); // 4. 批量插入评分明细 List<EvaluationResult> results = new ArrayList<>(); for (ScoreItem item : request.getScores()) { EvaluationResult result = new EvaluationResult(); result.setSubmitId(submit.getId()); result.setTaskId(request.getTaskId()); result.setStudentId(student.getId()); result.setTeachInfoId(request.getTeachInfoId()); result.setIndicatorId(item.getIndicatorId()); result.setScore(item.getScore()); results.add(result); } resultService.saveBatch(results); return JSONResult.success("评价提交成功"); }

注意这里事务只对运行时异常回滚，如果遇到检查异常比如FileNotFoundException，默认是不回滚的。所以要显式声明rollbackFor = Exception.class，确保任何异常都回滚。另一个细节是saveBatch内部其实是分批插入，真正执行的时候是把List拆成多个SQL，但整体还在当前事务里，所以仍然安全。

4.4 教师端统计报表查询优化

教师端要展示的数据其实挺复杂：自己被评了哪些课、每一门的平均分、每个指标的平均分、参与评价的学生数量。如果直接在Service层用Java代码循环查库，会出现N+1查询问题，就是查一次课程列表然后循环查分数，课程多了以后接口响应时间直线上升。

我改成了Mapper里写一条聚合SQL，把该教师所有课程的评价统计一次性查出来：

SELECT t.course_code, t.course_name, COUNT(DISTINCT r.student_id) AS eval_count, ROUND(AVG(r.score), 2) AS avg_score FROM evaluation_result r JOIN teach_info ti ON r.teach_info_id = ti.id JOIN course t ON ti.course_id = t.id WHERE ti.teacher_id = #{teacherId} AND r.task_id = #{taskId} GROUP BY t.course_code, t.course_name ORDER BY avg_score DESC

这种一条SQL解决统计需求的写法，在展示上非常直观。实际项目里我还用了MyBatis Plus的LambdaQueryWrapper做了动态拼接，比如过滤学期、过滤课程名称模糊查询，写起来比XML里拼条件舒服得多，而且类型安全，编译期就能发现字段名的错误。

5. 从源码到运行：拿到项目后如何快速跑起来

5.1 环境要求与准备清单

这套源码拿到手之后，第一件事不是打开IDE狂点运行，而是把环境准备好。需要的东西不多，但版本要匹配，我用表格列一下：

还有一点，Maven的settings.xml一定要配置阿里云镜像，不然拉Spring Boot的依赖能卡一个小时。这个是最影响效率的细节，很多新手卡在"项目导入后一直转圈"其实是镜像问题。

5.2 数据库初始化的两个关键坑

项目里带了sql目录，里面是建库脚本和初始化数据。执行的时候要注意两个事：

第一，先手动创建数据库再执行脚本，数据库字符集指定utf8mb4：

CREATE DATABASE IF NOT EXISTS evaluation_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

有些MySQL版本默认字符集是latin1，直接执行建表脚本会导致中文乱码。utf8mb4比utf8多支持emoji和一些特殊字符，现在写SQL脚本我都是无脑utf8mb4。

第二，检查脚本里的DEFAULT值有没有用0填充的日期。如果MySQL的sql_mode里带了NO_ZERO_DATE，某些初始化数据的日期是"0000-00-00 00:00:00"的话，脚本会直接报错。处理办法是执行前先查询：

SELECT @@sql_mode;

如果有NO_ZERO_DATE，就临时改成允许或者把脚本里的零日期改成正常的日期。这个坑非常隐蔽，报错信息也不直观，我帮好几个同学排查过都是这个问题。

5.3 Spring Boot启动与页面访问验证

数据库初始化好之后，修改application.yml里的数据库账号密码，然后启动Application类。启动成功后，日志里会看到Tomcat started on port 8080，这时候打开浏览器访问localhost:8080，看到登录页就说明框架搭起来了。

账号密码在sql初始化脚本里，管理员默认是admin/admin123，学生和教师也有对应的演示账号。建议启动后第一件事不是急着改代码，而是把三个角色都登录一遍，把核心流程走通。比如管理员登录后创建一个评教批次并关联课程，然后学生登录去评教，最后教师登录看统计。流程走通了说明环境没毛病，接下来逐行看代码才有参照物。

6. 实战踩坑记录与调试经验

6.1 MyBatis Plus分页查询不生效

分页插件配置完但查出来还是全量数据，这个问题特别常见。原因基本就一个：分页拦截器没有生效。MyBatis Plus 3.4之后的版本，分页插件类名和包名都变了，如果按老代码配了旧包名的拦截器，Spring Boot启动时不会报错，但分页就是不生效。

正确写法是这样：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

关键在DbType.MYSQL这个参数，一定要写。不写的话某些场景下插件不知道用哪种数据库的方言，分页SQL生成不对。排查方法也简单，打开MyBatis的SQL日志，看控制台打印的SQL里有没有LIMIT关键字，没有就是拦截器没配上。

6.2 前端Thymeleaf页面取值Spring Boot版本兼容问题

2.7.x版本的Spring Boot整合Thymeleaf没什么大坑，但如果用3.x的话，Thymeleaf版本不匹配会导致页面渲染时报一堆异常。这种问题排查起来很费时间，因为报错信息往往指向的是页面里的某个标签，但根因却是jar包版本冲突。

建议的做法是不要自己指定Thymeleaf的版本号，让Spring Boot的BOM来管理。如果是扩展了Thymeleaf的功能比如layout方言，那就要特别小心版本，layout方言2.x只支持Thymeleaf 3.0.x。这些细枝末节最影响开发体验，与其花时间折腾版本，不如老老实实用Boot 2.7.x全家桶。

6.3 评教结果统计的并发与数据一致性

最后说一个比较深的点，统计报表的并发一致性问题。如果多个学生同时提交评教，教师端的统计接口正好在跑聚合SQL，会不会读到中间态的数据？

实际上，因为整个评教提交是事务性的，在事务提交之前，别的请求是看不到未提交的数据的。MySQL默认的隔离级别是REPEATABLE READ，事务内的读操作是快照读，所以统计接口要么看到提交前的状态，要么看到提交后的完整状态，不会看到只插了一半的脏数据。

真正要注意的是前端展示的实时性。如果统计加了Redis缓存，那么学生提交完评教后要主动删缓存或者让缓存过期，否则教师端看到的还是旧数据。毕设阶段不需要引入Redis，直接查库最省心，但在答辩时把这个"缓存一致性"的问题自己想明白，能体现出你对系统设计的深度理解。

我个人的做法是，评教结果统计接口压根不缓存，因为评教不是高并发场景，一个学期的评教也就几百个学生提交，数据库扛这点压力绰绰有余。对非热点数据，缓存带来的复杂度远超收益，这个思路在很多系统设计里都适用。

7. 一套源码的二次开发方向

源码拿到手别急着交差，毕设答辩时老师一定会问"你觉得这个系统还有什么可以改进的地方"。我列几个我自己思考过的方向：

• 增加图表可视化，用ECharts把教师评教得分趋势、指标得分雷达图画出来，前端展示效果会好很多
• 评价文本分析，在打分之外增加文本意见输入，用简单的关键词统计做情感分析
• 多维度对比，按学院、按职称、按课程类别做评教得分的横向对比
• 消息通知，评教任务开启时自动给未提交的学生发邮件或站内信提醒

这些方向都基于现有源码的合理扩展，难度递增，挑一个做出来就是实打实的加分项。我个人觉得图表可视化性价比最高，因为能直观展示工作量，而且ECharts的官方文档很清楚，照着示例改数据格式就行。有一次帮一个同学加雷达图，从开始到上线只用了两天，包括对指标权重的展示。

写了这么多，核心就一句话：这套Spring Boot高校学生评教虽然不复杂，但把常用的后端技术点串了起来，从三层架构到拦截器、事务、聚合查询都有落地场景。系统收集了评教数据之后，在管理员导出报表那一块还能再玩的花样很多，比如和往期评教做对比、生成教师教学质量分析报告。有需要的朋友，把这篇文章和源码结合着看，比单纯复制粘贴代码的理解深度要高一个层次。