高校评优管理系统JavaWeb实战：Spring Boot+MyBatis-Plus全解析

做毕设选了“高校评优管理系统”这个题目，用 java 技术栈来落地，本质上是一个非常典型的 JavaWeb 信息管理类项目。这类系统放在多年前，可能还叫 JSP + Servlet + JDBC 时代的老三样，但放到现在，比较合理的形态是 Spring Boot + MyBatis/MyBatis-Plus + MySQL + Vue（或者 Layui）前后端分离（或半分离）的结构。这篇文章我不会把某一个开源项目的代码直接贴上来给你抄，而是把“高校评优管理系统”这类项目背后的核心设计思路、关键实现环节、数据库表设计逻辑、常见的坑和排查方法讲清楚，带着你把整个系统的骨架搭起来。

先说一下这个系统到底在解决什么问题。高校里的评优工作，比如优秀学生、优秀学生干部、优秀班集体、三好学生、奖学金评定、优秀教师评选等，通常涉及信息收集、材料申报、在线打分、结果汇总、公示存档这几个环节。线下操作的问题是数据分散在表格和邮件里，打分过程不透明，结果汇总容易出错，而且不好追溯。评优管理系统的核心任务就是把“申报-审核-评审-公示-统计”这条流程线上化。对于毕设而言，这意味着系统有明确的实体关系、角色权限、流程状态变动和统计查询需求，是天然的 JavaWeb 综合训练项目。

1. 系统全景拆解：先搞懂角色与业务闭环

1.1 三类核心角色与权限边界

高校评优管理系统虽然每个学校的业务细节不太一样，但角色模型基本是一致的，就是三类人：学生、教师（辅导员/班主任/评委）、管理员（学院教务或学生处工作人员）。搞清楚这三类角色想干什么，系统几乎就设计完了一半。

学生端主要是申报和查询。学生登录系统之后，能看到当前开放的评优项目，填写个人申报信息，上传佐证材料（成绩单、证书照片、活动证明等），然后提交。提交后能看到审批进度，包括辅导员是否已经审核、评审老师是否已经打分、最终是否公示、自己有没有被评上。所以学生端功能可以拆成：项目列表、申报填写、材料上传、进度查看、结果查询、个人中心。

教师端的核心是审核与评价。教师可能是两种身份，一种是辅导员/班主任，负责对学生申报材料的真实性做初审，另一种是评委，负责按评分指标对候选人打分。在系统设计上，这两种身份可以都归属于教师用户，用角色字段或功能权限来区分。教师端主要功能包括：待审核材料列表、材料在线查看、审核通过/驳回操作、评审打分表填写、打分结果提交、已处理记录查询。

管理端是系统的中枢，权限最高。管理员负责创建评优项目、配置评审规则（哪些评分维度、各维度权重多少）、设置评选批次和时间窗口、管理用户和班级基础数据、审查整个流程进度、发布公示名单、导出汇总表。管理员端功能最多，包括用户管理、项目管理、评分模板配置、流程监控、结果发布、数据统计、系统日志等。

1.2 业务状态流转是整个系统的主动脉

评优管理系统最容易写乱的地方就是状态管理。一个评优申请从诞生到结束，状态是不断变化的，系统里的每一次操作几乎都伴随状态更新。把这套状态流转理清楚，业务逻辑就不会乱，数据库表也不容易设计成纠成一团的“屎山”。

我建议把主干状态定义为以下五个阶段：

• 待审核：学生已提交申报，辅导员/班主任还没有处理。
• 已通过（初评通过）：材料审核通过，进入评审打分环节。
• 已驳回：材料不合规，被退回，学生能看见驳回原因并进行修改后重新提交。
• 评审中/待打分：评委需要对通过初审的申请进行评分。
• 已公示/已评优：打分结束，管理员汇总结果并公示，流程结束（结果可存为历史记录）。

这里每个状态变化都应该记录到日志表里，方便追溯。数据库在实现时，一般在申请表里加一个 status 字段（建议用整数或短字符串，比如 0 待初审、1 初审通过、2 已驳回、3 评委评分完毕、4 已公示），同时加一张 audit_log 表记录每次操作的操作人、操作时间、操作内容、变更前状态和变更后状态。日志表的作用不只是毕设答辩时给老师看“系统设计完备”，更是排查问题时的第一手线索。

2. 技术选型解析：这套组合为什么是当前毕设的合理答案

2.1 后端框架对比与选择逻辑

现在做 JavaWeb 毕设，选型上其实没有太多悬念：Spring Boot 是首选。原因很直接：Spring Boot 内嵌 Tomcat，省去部署 war 包和单独配置 Tomcat 的麻烦；自动配置机制减少了大批 XML 配置；spring-boot-starter-web 一行依赖就能把 Web 环境拉起来；配合 application.yml 做数据源和各类参数配置，直观好改。这些都是对新手极其友好的特性。

传统 SSM 框架（SpringMVC + Spring + MyBatis）虽然在很多教材里还在讲，但实际操作时包的版本冲突、XML 配置互相引用、容器部署老出问题，经常让新手花费大量时间在环境调试而不是业务开发上。Spring Boot 在 SSM 之上解决了这些“人肉配环境”的痛点，但底层的 MVC 思想完全没变，答辩时还是能讲清楚。

持久层方面，MyBatis-Plus 比 MyBatis 更推荐。MyBatis-Plus 提供 BaseMapper 和通用 Service，单表 CRUD 连 SQL 都不用写，直接用 wrapper 条件构造器就能实现条件查询、分页、更新。省下来的时间可以集中写复杂的统计 SQL 和业务逻辑。需要注意，用 MyBatis-Plus 时，分页要配置 PaginationInnerInterceptor，否则 Page 对象的查总数功能不生效，这个是最常见的隐性坑。

2.2 前端方案：Layui 与 Vue 的取舍

前端选型上，如果你的重点是把后端业务写清楚、尽快跑起来，我强烈推荐Layui。Layui 是一个后端程序员友好型的前端框架，提供表格、表单、弹窗、分页、日期选择等组件，直接通过 layui.use 加载模块、用 table.render 定义列模型就能渲染数据表格，不需要单独构建工程。做一个后台管理类系统，Layui 的 table 组件配合后端返回的 Page 数据结构，几乎是一天就能打通前后端数据流。

如果你对前端有一定基础，可以选 Vue 2 + Element UI 做前后端分离。这种方案的优点是页面美观、交互流畅，毕设答辩时视觉效果更好，但工作量会增加很多，比如要处理跨域（CORS）、Token 鉴权、路由守卫、Axios 封装、环境变量配置等。一个评优管理系统的核心价值在于业务流程实现，而不是页面动画，所以我不建议把太多时间花在解决 Vite、跨域、打包这些问题上。

用 Layui 的话，前端页面可以放在 Spring Boot 的 static 目录或 templates 目录下，用 Thymeleaf 做简单的模板渲染，数据交互则用原生 Ajax 或 jQuery 的 $.ajax 调后端接口。这套模式部署简单、查问题也直观。如果你想做出一点亮点，也可以把 Layui 的 table 和 echarts 图表组合起来，在首页做评选比例、各学院参评人数、项目类型分布的图表展示，提高答辩的展示分。

2.3 环境与基础工具清单

给读者列一下我推荐的基础环境版本，避免新手在版本匹配上栽跟头：

这里特别提醒一下 JDK 版本问题。我看到很多热搜词里有“java环境变量配置”“java安装教程”这些。如果你用的是 JDK 8，环境变量主要配 JAVA_HOME、PATH、CLASSPATH 三个；如果用的是 JDK 11 以上，很多场景不需要 CLASSPATH 了，但 javac 和 java 命令要在 PATH 中能找到。判断环境是否配好，在命令行输入 java -version 和 javac -version，都不报错就是配置成功。没什么特殊的技巧，唯一要注意的就是 PATH 和 JAVA_HOME 别写错，尤其是 Windows 下路径中的反斜杠和分号不要漏。

3. 数据库设计：评优系统的表结构这样设计最清晰

3.1 核心数据实体与表关系

评优管理系统的数据模型是整个系统的地基。我见过很多毕设项目，表设计随意、字段命名没有规范、表之间没有外键意义上的关联，导致后面写 SQL 统计时到处 JOIN 都查不对数据。如果你是从零开始设计，按照下面的核心实体去展开，基本不会漏：

学生信息表（student），字段包括：学号、姓名、性别、班级 ID、政治面貌、入学年份、联系方式、账号状态。这里学号可以作为唯一索引，也可以直接用自增主键 + 学号唯一约束，不要把学号当主键（虽然字符串主键也能用，但性能和数据规范性都不如自增主键）。

教师信息表（teacher），字段包括：工号、姓名、所属学院、角色（辅导员/评委）、职称、联系方式。教师账号也可以单独建 user 表，与教师信息表一对一关联。

用户表（sys_user）：建议单独建一张用户表来保存登录账号、密码（MD5 加盐或 BCrypt 加密）、用户类型（学生/教师/管理员）、状态（启用/禁用）。用户表和 student/teacher 表用 user_id 关联，这样登录逻辑统一、权限处理也简单。

评优项目表（evaluation_project），字段包括：项目名称、项目类型（三好学生/优秀学生干部/优秀班级/优秀教师等）、评选学年/学期、报名开始时间、报名截止时间、评审开始时间、公示时间、项目状态（草稿/报名中/初审中/评审中/已公示/已归档）、评分规则 ID、创建人。

评分模板表（score_template）与评分指标表（score_indicator）。一个评优项目可以有多个评分维度，比如学习成绩权重 40%、综合素质 30%、民主评议 20%、答辩表现 10%。权重加起来是 100，每个维度对应一条 score_indicator 记录，值域可能是百分制或十分制。打分时按项目 ID 查出指标列表，评委根据每个指标给分，再按权重加权汇总出总分。

申报表（apply_record），这是业务核心表，字段包括：ID、评优项目 ID、申请人 ID（学生 ID）、申报类型、个人总结、思想品德自评、成绩排名/绩点、附加材料路径（JSON 数组或逗号分隔字符串）、状态、总得分、审核人 ID、审核意见、审核时间、评委人数、最终结果等。这张表既要承接申报信息，又要存评审结果，设计时可以把评审结果拆出去，也可以直接在表里冗余一个总得分字段，查询时快很多。

评分记录表（score_record），字段包括：申报记录 ID、评委 ID、指标 ID、分数、评分时间。一个评委针对一个申报记录可能有多条指标评分记录，所以按指标维度存比较合理。汇总平均时，针对同一个 apply_record_id 聚合 sum(score * weight) / 数量 或 avgerage，就能得到总分。

公示记录表（publicity_record），字段包括：评优项目 ID、批次、公示内容（或关联的申报记录 ID列表）、公示开始时间、结束时间、状态。公示可以做成定时或管理员手动发布，功能上主要是展示和历史查询。

日志表（operation_log）：用户 ID、操作类型、操作描述、请求 IP、操作时间。日志表在毕设答辩中是一个非常好的加分点，能体现系统设计上的完整性。

3.2 核心表字段设计的几个具体建议

字段类型上，我见很多人喜欢用 varchar(255) 存所有字符串，因为省事，但会影响索引和查询性能。比如学号和工号，用 varchar(20) 就足够；成绩绩点这种数值，用 DECIMAL(5,2) 而不是 float/double，因为浮点数在数据库里会有精度问题。状态字段建议用 int 或 tinyint，配合后端项目里的枚举类或常量类去解释，不要直接在 SQL 里用字符串比较，可维护性会好很多。

材料存储是一个容易忽略的点。申报材料（证书照片、成绩单截图、文档）如果直接存到数据库里变成 blob 或 longblob，既浪费数据库空间，又会让查询变慢，而且备份也很痛苦。比较靠谱的方式是文件上传到服务器的指定目录（或本地磁盘路径），数据库里只存文件相对路径或 URL。上传目录建议配置一个常量或写在 application.yml 里，比如 upload.dir=/data/evaluation/uploads，相应地在 Spring Boot 里配置资源映射，让上传的文件可以通过 http://localhost:8080/files/xxx.jpg 访问到。这个设计思路简单，但也体现了一个后端开发者的基本素养：静态文件不要塞进数据库。

成绩排名和绩点数据的导入值得单独考虑。有的学校希望学生手动填，有的学校希望直接抓取教务系统的数据，但毕设通常手动填就够了。建议在申报表中，除了手动填写的分数字段，再存一个“成绩排名/总人数”，比如“3/120”，这样评委不需要去对比课程成绩单，直接看排名数据即可完成初步判断。

4. 后端核心业务实现：这些模块要这样写才不乱

4.1 统一返回结构，前端才好接数据

写接口的时候一定要统一返回值格式，这可能是后端开发最基本的约定之一。系统里所有 Controller 的方法，要么返回一个统一的 Result 对象，要么通过 @RestControllerAdvice 做全局异常处理时统一返回格式。我个人习惯用一个 Result 类：

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

前端拿到 code 为 200，就取 data 渲染；code 不是 200，就弹出 message。别看这个类简单，如果能强制团队里所有人写接口时都返回 Result，后端联调阶段会少吵一半的架。分页接口统一返回分页数据结构，比如 PageResult （包含 total、records、current、size），前端 Layui 的 table 只用匹配它的数据格式就行。

4.2 登录鉴权与权限拦截：用最稳的方式做

毕设项目在登录鉴权上，我建议优先使用 Session 或 JWT，但不要两种一起上，反而混乱。如果要完全前后端分离，用 JWT 会比较顺理成章：用户登录成功后后端签发一个 token，前端存储在 localStorage，请求时放在请求头 Authorization: Bearer xxx，后端用一个拦截器或过滤器解析 token。

如果前端是 Layui + 服务端渲染 / Ajax 半分离模式，用 Session 也可以，每次请求通过拦截器判断 session 里有没有登录用户。用 Session 的好处是后端代码逻辑更直接，不用自己实现 token 解析和过期处理，浏览器自动维护会话；缺点是前端如果做纯静态部署，跨域时会话管理会有点绕。但毕设系统中，用 Session 依然是最简单的方案。

我更推荐 JWT 方案，因为能顺带讲清楚 token 鉴权的原理，在答辩时更有“技术含量”。拦截器可以这样写：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口 if (request.getRequestURI().contains("/login")) { return true; } String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); try { // 解析token，一般用JWT工具类 Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); request.setAttribute("userType", claims.get("userType")); return true; } catch (Exception e) { response.setStatus(401); return false; } } response.setStatus(401); return false; } }

JWT 的 payload 里，不要放密码等敏感信息，放 userId、userType、用户名就够了。过期时间可以设计为 2 小时，header 里带一个 refresh 或重新登录的机制，但毕设简化成过期就重新登录也没问题。

4.3 评优打分与权重计算的正确打开方式

这是整个系统业务逻辑最重的部分。一个优秀的评优评审算法，并不需要用到多复杂的数学公式，关键是理解“多人打分 + 多维度权重 + 最终汇总”这个过程。

假设三好学生评选的打分维度是学习成绩（权重 40%）、思想品德（20%）、综合素质表现（20%）、民主评议（20%）。评委 A 给某个学生打分，四个维度分别是 90、85、88、80；评委 B 的打分分别是 92、84、86、82。那么该学生的总得分怎么做：

第一步，每个评委的打分都要乘以对应权重相加，得到该评委的加权总分。

评委 A 总分 = 90 × 0.4 + 85 × 0.2 + 88 × 0.2 + 80 × 0.2 = 87.4 评委 B 总分 = 92 × 0.4 + 84 × 0.2 + 86 × 0.2 + 82 × 0.2 = 87.2

第二步，取多个评委总分的平均值，就得到学生的最终得分：(87.4 + 87.2) / 2 = 87.3。

代码实现时，score_record 表按 apply_record_id + evaluator_id + indicator_id 存储原始分。汇总阶段，先按指标查出所有分数，按权重计算并求平均。SQL 可以用一条 GROUP BY 查询，也可以在 service 里循环计算。如果是毕设，service 层循环计算更直观、更好讲，代码也更不容易出 bug。

需要注意，权重字段在 score_indicator 表里存的是整数（比如 40），计算时要除以 100.0，否则 int 除以 int 直接变 0。这种低级错误我见过好几次。

4.4 项目状态流转的控制逻辑

评优项目的状态（草稿、报名中、初审中、评审中、已公示、已归档）决定了对某个项目用户能执行什么操作。管理员创建项目之后，初始状态是草稿（0）；管理员发布项目，状态变为报名中（1）；报名截止，状态变为初审中（2）；初审完成，可以进入评审中（3）；全部打分完毕且管理员确认，变为已公示（4）；公示结束归档，变为已归档（5）。

后端比较好落地的方式不是在各个接口里到处 if-else 判断“当前状态如果等于几才能执行什么操作”，而是抽一个状态机枚举类：

public enum ProjectStatusEnum { DRAFT(0, "草稿"), ENROLLING(1, "报名中"), REVIEWING(2, "初审中"), EVALUATING(3, "评审中"), PUBLICIZED(4, "已公示"), ARCHIVED(5, "已归档"); private final Integer code; private final String desc; // 省略构造函数和getter }

然后每个更新状态的方法，都在 service 层先校验“当前状态 == 允许的前置状态”，如果不符合就直接抛业务异常。这样虽然代码稍微多写几行，但流程严谨，数据不会出现“评审中还能报名”的诡异情况。答辩时老师问“你怎么保证状态不跳变”，你就可以拿这张状态机表讲一下设计思路。

4.5 通知与公示功能：不要只做 CRUD

评优管理系统如果只是表格增删改查，确实只能算及格。想做得更有亮点、更贴近真实业务，你可以在系统里加一个通知公告模块。学生提交申报之后，状态变化（比如审核通过、被驳回、进入公示期），系统可以给用户生成一条站内消息。实现方式很朴素：建一个 notification 表，包含接收用户 ID、内容、类型（系统通知/审核结果/公示提醒）、是否已读、创建时间。管理员发布公示或批量通过时，在 service 层批量插入通知记录。

这个功能做起来工作量不大，但对用户体验提升非常明显，学生在首页能直接看到“您的材料已通过初审，进入评审打分阶段”这样明确的进度提示，比自己去翻申请单状态强得多。首页还可以把待办事项（学生待提交、教师待审核、管理员待处理）也做成提醒卡片，整个系统立刻就“活”了，不再是冷冰冰的 CRUD。

4.6 Excel 导入导出：批量数据进出的基石

评优系统有大量数据需要导出：评审结果汇总表、学生申报信息表、学院申报统计表。导出用 Apache POI 或 EasyExcel 都可以。EasyExcel 的注解式模型映射比 POI 手写 workbook 类代码简洁很多，但需要引入依赖并理解数据模型定义。如果你想要简单直接，直接上 POI 的 XSSFWorkbook 也能写，就是代码量大一点。

导入场景主要是管理员批量导入学生名单。整体方案是：前端上传 Excel，后端解析文件流，逐行读数据生成 Student 对象并批量插入数据库，校验失败的行记录错误信息并返回给前端。做导入时关键是要做好格式校验：学号不能为空、重复学号要提示、姓名不能包含特殊字符。不要为了炫技写太复杂的校验逻辑，核心是“错了要给用户明确的提示，而不是默认吞掉错误”。

5. 前端页面设计与交互：评优系统的“门面”工程

5.1 页面结构划分与信息架构

前端页面结构与用户角色强相关，但我建议做一个总的后台管理布局：顶部导航栏显示系统名称和当前登录用户，左侧菜单根据角色动态渲染。学生登录后只看到申报中心、我的申报、成绩查询、通知公告；教师登录后看到审核任务、评审打分、历史记录；管理员登录后看到全部菜单。

具体页面可以这样规划：

• 登录页：账号、密码、验证码（可以自己生成简单图形验证码或跳过，用 Redis 做校验）。
• 首页/ dashboard：显示当前评优项目和进度统计（图表）。
• 申报列表页：展示当前开放的项目，点“申报”进入表单页。
• 申报表单页：必填字段、材料上传、提交按钮。
• 材料审核页：教师查看申报详情，选择通过/驳回并填写意见。
• 评审打分页：评委逐项打分、实时显示加权总分预览。
• 公示管理页：管理员发布公示列表、查看公示详情。
• 用户管理页：管理员维护学生与教师账号。

5.2 Layui 表格动态数据渲染要点

Layui 的 table 组件是最常用的，核心是 table.render 函数。比如管理员查看项目列表，写法类似：

table.render({ elem: '#projectTable', url: '/admin/project/list', method: 'GET', page: true, cols: [[ {field: 'id', title: 'ID', sort: true}, {field: 'projectName', title: '项目名称'}, {field: 'projectType', title: '类型'}, {field: 'statusDesc', title: '状态'}, {field: 'startTime', title: '开始时间'}, {field: 'endTime', title: '结束时间'}, {title: '操作', toolbar: '#projectBar'} ]], parseData: function(res) { return { code: res.code, msg: res.message, count: res.data.total, data: res.data.records }; } });

后端接口只要返回 { code: 200, message: "", data: { total: 100, records: [...] } } 就能对接上。这里最容易出的问题就是返回数据结构和 Layui 期望的数据结构不一致，注意 parseData 做一次适配即可。

表格操作列的按钮事件绑定用 table.on('tool(...)')，比如点击“审核”弹出一个详情页或表单页，可以用 layer.open 加载子页面，也可以 iframe 嵌一个详情页面。毕设系统建议用 iframe 弹窗方式，代码拆得清楚，页面之间互不干扰。

5.3 表单校验与富文本编辑的选型

学生申报时需要填写个人总结、心得体会这类长文本，直接用 textarea 体验不太好，但也没必要引入重量级富文本编辑器。如果需要排版稍微好看一点，Layui 自带的 layedit 模块可以做简单的富文本。不过注意 layedit 在弹出层中初始化时可能会有渲染问题，遇到这种情况可以把编辑器初始化放回主文档，或者改用 textarea + 简单的 HTML 标签支持。如果不想处理这类小毛病，普通 textarea 加合适的 CSS 高度其实就能满足毕设需求。

所有表单提交前做前端校验（Layui 的 lay-verify 支持必填、长度、手机号格式等），后端再校验一次。前端校验是体验，后端校验是底线，不要省。

6. 常见问题与排查技巧实录

6.1 环境启动类问题

我在给不少同学调试毕设时发现，真正卡住他们超过半天的问题往往不是业务代码，而是环境。整理几个出现频率最高的问题：

第一个是 Tomcat 端口被占用。Spring Boot 项目启动报 Port 8080 was already in use，处理很简单：修改 application.yml 里的 server.port，或者用命令找出占用进程并结束它。Windows 用 netstat -ano | findstr 8080，然后 taskkill /F /PID 对应进程号。这是最基础的一组命令，必须会。

第二个是 MySQL 驱动版本和连接串问题。如果你用 MySQL 8.0，驱动类名是 com.mysql.cj.jdbc.Driver，URL 要加 serverTimezone=Asia/Shanghai 和 useSSL=false，不然启动时报时区错误或 SSL 连接错误。这个坑在 Spring Boot 2.x 中非常典型。

第三个是 JDK 版本不匹配。Lombok 在较新的 JDK 版本上可能报“You aren't using a compiler supported by lombok”之类的错误，解决方法是去 Lombok 官网找对应支持的新版本，或者直接换 JDK 1.8，别跟版本死磕，没有意义。

第四个是 Maven 依赖下载慢或失败。国内默认 Maven 中央仓库经常超时，建议在 settings.xml 里配置阿里云镜像。这个操作很简单，但真的能省一晚上的时间。

6.2 接口联调类问题

前后端联调时最常见的报错就是跨域问题。如果用了 Layui 放在后端 static 下，同源部署基本无跨域；如果用 Vue 单独跑 dev server，访问后端接口时一定会有跨域，这时要么后端写全局 CORS 配置，要么前端配代理。如果选型是前后端分离，建议在 Spring Boot 里直接写一个 WebMvcConfigurer 配置允许跨域。

另一个高频问题是参数接收不到。前端传了 JSON，后端 Controller 用普通对象接收，却没有加 @RequestBody，导致前端明明传了数据但后端取到 null。判断方法很简单：如果请求头是 application/json，且传的参数是对象类型，Controller 就一定要用 @RequestBody 接收；如果是表单提交，对象形参才能像 Spring MVC 那样自动绑定。这个知识点面试时也经常被问到，值得记牢。

6.3 数据与业务逻辑类问题

申报记录提交后，学生端总是看不到材料，最常见原因是文件上传路径配置和资源映射没做。文件存在本地 uploads 目录，但访问不到，解决方法是配置静态资源映射：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/files/**") .addResourceHandler("file:" + uploadDir + "/"); } }

评分汇总计算出来的总分不对，优先查权重是不是除以 100 了，另外注意数据库里 score_record 的指标分数是否可能为空。只要有一个评委没打分或者某个指标没录，聚合时 SUM 包含 null 会导致结果不准，用 COALESCE(score, 0) 兜底。

页面列表数据有缓存现象，修改后刷新不生效，先排除浏览器缓存问题，再检查后端查询接口有没有作分页或条件过滤，最后看 Layui table 的自动渲染行为。有时候是因为数据确实改了，但 Layui 表格没有 reload，加一行 table.reload('tableId') 就能解决。

6.4 内存溢出问题

热搜里也有 outofmemoryerror: insufficient memory 这条。如果是 IDEA 里运行项目内存溢出，调整 JVM 参数：Help -> Change Memory Settings 或修改运行配置的 VM options，比如 -Xms256m -Xmx1024m。如果是导出大数据量的 Excel 时堆内存不够，建议用 EasyExcel 的流式写，不要一次性把全量数据加载到内存再导出。还有一个常见场景是在本地 Debug 跑分页查询时，如果 MyBatis-Plus 的分页插件没配置 PaginationInnerInterceptor，Page 查出来的 total 总是 0，甚至可能 N+1 查询导致内存膨胀。这些都是可以在开发阶段立即修正的问题。

7. 我的一些个人心得与建议

最后说一点这个项目怎么做到既省力又能拿高分的个人经验。

第一，代码规范明确胜过花里胡哨。统一 Result 返回结构、统一异常处理、分层清晰（Controller -> Service -> Mapper）、核心业务类有注释、状态字段有枚举，这些足够撑起“设计规范”的分。老师不一定看得完你的代码，但打开项目扫一遍目录结构、看几个核心文件，代码风格好不好一目了然。

第二，重点模块要能“讲得出话”。整个系统有很多功能，但最好挑选两三个模块深度准备好讲解：数据库表为什么会这样设计、评委打分时多维度权重是怎么计算的、多角色权限是怎么控制的、拦截器是怎么工作的。把业务和技术结合清楚，远比在文档里堆一千页流程图有用。

第三，可以扩展的方向不要贪多。如果时间有多余，我最建议做的扩展是“评分结果数据可视化”和“按批次导出 PDF 公示名单”，前者用 ECharts 就能搞定，后者用开源的模板引擎生成 PDF 也行。不太建议加过于复杂的功能，比如问卷调查、自动抓取教务系统成绩、短信通知，功能越多，历练越大，出 bug 的熵也越大。毕设的核心目标是在有限时间里完整交付一个逻辑自洽、能跑能讲的应用，而不是做一个大而全的商业平台。

高校评优管理系统就是一个典型的 JavaWeb 综合应用，把这个系统的开发逻辑吃透之后，你会发现类似“高校社团管理系统”“实验室管理系统”“班级事务管理系统”都是同一类套路，角色换成社团/实验员/班委，业务换成另外一套流程，表结构和模块划分几乎可以复用七成以上。把评优系统做扎实了，一整个 Spring Boot + 前端 + 数据库的技术链路也该入门了。