Spring Boot大学生评优评定系统：设计开发与部署实战

1. 项目背景与需求梳理

先聊点实际的。我在和一些高校的同学交流时发现，“评优评先”这件事在很多学院里还停留在一个相当原始的阶段——辅导员发一张Excel表下去，各班班长手动填写，收上来之后辅导员再逐个核对、汇总、加权计算，最后把结果公示。整个过程至少三到五天，还容易出错：格式不统一、加分项漏填、某位同学提交的证明材料图片模糊，更头疼的是不同年级的评定规则还不一样，一张表根本套不住所有人。

“springboot188大学生评优素质评定管理系统的设计与实现”这个项目，本质上是把这个从“填表→收表→校对→汇总”的线下流程，搬到一个Web系统里做线上化、规范化、可追溯化。系统要解决的核心问题有三个：第一，评定规则可配置，不靠人为解释；第二，打分和材料提交有迹可循，不能事后扯皮；第三，汇总和排名自动完成，减少人工算分的低级错误。

从技术角度看，这个项目选型非常典型。Spring Boot作为后端框架，MyBatis-Plus做ORM，MySQL存数据，前端采用Vue或Thymeleaf做界面渲染，整套组合是当前JavaWeb方向最主流的套路。它的受众非常明确——计算机专业做毕业设计或者课程项目的同学，以及那些想转型Java后端开发、需要一个完整项目练手的人。

不管你是只想要一个能跑起来交差的Demo，还是想把它做深、做全，这个项目的核心链路都是绕不开的：用户登录鉴权、学生信息维护、评定指标配置、打分录入、成绩自动汇总、结果排名公示。本文会沿着这条链路把设计思路和实现细节完整拆一遍，先把整体架构说清楚，再落到关键代码和数据库设计上，最后把开发过程中最常见的坑和排查思路整理成表格，方便你遇到问题的时候直接对照。没废话，直接开始。

2. 系统功能模块与角色权限设计

2.1 角色划分：谁在用这个系统

评优评定系统和使用教务系统不一样，它不是一个人从头点到尾，而是多个角色配合使用。我在设计系统的时候第一件事不是写代码，而是先梳理用户角色，角色定了，权限边界自然就出来了，后面的页面和接口也才好拆。

这个系统正常会划分四种角色：

• 学生：查看自己的基本信息、填写综合素质自评、上传证明材料、查看评定结果。
• 辅导员（班级负责人）：审核班级学生的自评材料、为所带班级学生打分、查看班级排名。
• 院系管理员：维护本院系的专业和班级信息、配置评定指标权重、审核辅导员提交的结果、导出报表。
• 系统管理员：全局管理，控制用户账号、重置密码、配置全局的评定批次和规则。

每个角色能看的页面、能点的按钮都不一样。比如，学生能填自评却改不了其他同学的分数，辅导员能打分但改不了权重配比，管理员能配权重但不会去替辅导员打分。这种分权设计不单是为了安全，更多是为了让各环节的责任边界清晰——谁录入、谁审核、谁发布，每一步都有迹可循，出了问题可以回溯到具体操作人。

这种多角色模型也直接决定了后台接口的设计思路。我通常会采用Spring Security + JWT做登录认证和权限控制。JWT负责“你是谁”的问题，Security的注解权限模型负责“你能干什么”的问题。比如在Controller上标注@PreAuthorize("hasRole('ADMIN')")，就限定了这个接口只能由管理员调用。角色多了之后，这一层的约束千万别省，我之前见过不少项目把权限判断散落在业务代码里，结果改一处漏一处，维护起来非常痛苦。

2.2 功能模块拆解：从一次评优流程说起

要理解系统的功能模块，最直接的办法是跟着一次评优流程走一遍。

假设现在是每年九月的奖学金评定季。系统管理员先在后台创建一个评定批次，比如“2024-2025学年综合素质测评”，设置好起止时间。然后院系管理员在这个批次下配置评委角色——哪些老师是辅导员，哪些是材料审核员。接着，辅导员登录系统后，会看到本班学生的待评定列表，系统会展示每个学生的自评得分、申报奖项以及上传的佐证材料，辅导员可以在线打分或者驳回材料。所有有效分数提交后，系统自动计算总分生成排名，管理员确认排名后一键公示，学生端就能看到自己的等级和排名信息了。

顺着这条线拆，系统的核心模块至少包含以下几块：

• 学生信息管理：学生的学号、姓名、班级、政治面貌、联系方式等基础信息维护，支持Excel批量导入导出。
• 评定指标管理：这是整个系统的灵魂。综合素质评价一般分成思想道德、学业成绩、文体活动、社会实践、创新创业几个维度，每个维度下又有细化条目。指标要支持动态配置，比如今年学院规定“社会实践”权重提高到20%，管理员在界面上改一下就行，不用改代码。
• 材料申报与审核：学生按指标项上传对应的材料（获奖证书照片、志愿时长证明、论文录用截图等），辅导员逐条审核。审核不通过的要能回退并填写原因，方便学生重新提交。
• 打分与计算：支持多评委打分，系统按照配置好的权重自动计算加权总分。
• 结果排名与公示：按班级、专业、学院多维度排名展示，公示期内允许学生申诉。
• 通知公告：评定批次开启、截止、结果公示等关键节点自动发站内消息。

这六个模块基本覆盖了评优评定的全部业务场景。你可能会问，为什么学生自评也要放进流程？这其实是有讲究的。评优评定不只是学院单方面打分，学生的自我总结本身就是综合素质评价的组成部分。让学生填写自我评价、自我申报奖项，再配合辅导员审核，既锻炼学生的自我认知，也减轻辅导员逐项录入的负担。

2.3 数据库设计思路：表的拆分与关联

数据库表设计是整个系统的地基。地基没打好，后面写代码的时候就会到处别扭。我设计这类系统时通常会按照“基础数据—业务数据—过程数据—结果数据”四个层次来拆表。

基础数据表包括用户表、角色表、学生信息表、班级表、专业表。用户表存账号密码和身份标识，学生信息表单独拆出来存学号、姓名、入学年份、班级等学籍属性，两个表通过user_id关联。这么做的好处是以后系统要接入统一身份认证，或者增加教师用户，都不用动学生表的逻辑。

业务数据表就是评定指标表、指标分类表和批次表。指标表里要存指标名称、所属维度、满分值、权重，还有启停状态。这里有一个设计经验：指标表不要直接写死权重值，而是把权重和指标解耦。因为权重是跟着批次变化的，今年学业成绩占40%，明年可能调整为35%。把权重字段放在批次指标关联表里，每次评优可以复制一套指标配置再调整，历史数据不会受参数变化影响。

过程数据表是材料表和打分记录表。材料表是学生上传的佐证文件信息，包括文件路径、所属指标、上传时间、审核状态、审核人、审核意见。打分记录表则是核心流水账，记录评委ID、被评学生ID、指标ID、得分、打分时间，每一条都不可删除，只能追加更正记录。

结果数据表就是最终的排名结果表和公示记录表。排名结果由定时任务或手动触发计算后写入，公示记录存开始时间、结束时间和操作人。

这套库表设计在B站上能找到的很多教学项目里也能看到类似结构，差别主要在细节上。比如我会额外加一批逻辑删除字段（deleted），统一用MyBatis-Plus的逻辑删除能力，方便误删恢复；还会建一张操作日志表，记录谁在什么时间改了什么配置。这些细节平时看起来不起眼，但一旦项目要拿去答辩，面试官拿起表结构问设计思路的时候，你就能讲出东西来。

3. 技术选型与项目环境搭建

3.1 后端框架的取舍：Spring Boot + MyBatis-Plus的搭配逻辑

项目名为“springboot188”，技术栈自然是以Spring Boot为核心。Spring Boot这几年的地位根本不用我多说，它把Spring繁琐的XML配置全部干掉，内嵌Tomcat，启动一个Web项目从过去的一堆配置简化成了mvn spring-boot:run一行命令。就凭这一点，它就是JavaWeb项目首选，没有之一。

持久层框架我强烈推荐MyBatis-Plus。相比原生MyBatis，它最痛的点就是不用写大量的单表CRUD XML。内置的BaseMapper提供了selectById、insert、updateById等现成方法，配合LambdaQueryWrapper实现动态条件查询也极其顺手。比如查询某个班级的待审核材料列表，一行构造就出来了：

LambdaQueryWrapper<Material> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Material::getBatchId, batchId) .eq(Material::getStudentId, studentId) .eq(Material::getAuditStatus, 0); return materialMapper.selectList(wrapper);

这里的Material::getBatchId是Lambda表达式引用，IDE能追踪到字段，不存在SQL硬编码字符串写错的问题，编译期就能发现一部分低级错误。

需要说明的是，MyBatis-Plus并不是万能药。我见过很多同学在项目里遇到多表关联查询就手足无措，因为MP只擅长单表操作。碰到学生表、班级表、专业表连表查询的需求，该手写SQL还是要手写。好在这类报表查询不多，而且MP提供了分页插件，配合手写SQL也没太大违和感。

还有一点就是Spring Boot版本的选择。这个项目名里带“188”，不少教学项目会基于Spring Boot 2.7.x甚至2.3.x来搭，因为网上能找到的配套资料最多。我的建议是如果你是自己从零搭建，直接上Spring Boot 3.x + Java 17的组合也没问题，性能更好、安全更新也及时。但如果你是照着教程复现，教程用什么版本你最好保持完全一致，否则后来遇到版本的坑排查起来很浪费时间。

3.2 前端方案的考虑：Vue还是Thymeleaf

前端这块是很多做后端项目的同学最容易纠结的地方。我直接说重点。

如果你主要想体现Spring Boot的后端功底，而且项目周期紧张，用服务端渲染的Thymeleaf模板是最稳妥的。它把HTML页面和后端接口天然融合在一起，Controller返回视图名，模板里用th:each遍历数据渲染表格，不需要考虑跨域，不需要维护前后端分离的前端工程。很多教学项目用Thymeleaf就是这个道理——省事，好演示。

如果你想做得更完整一点，或者简历上想写“前后端分离开发经验”，那就选Vue 3 + Element Plus，通过Axios调用后端接口。前后端分离开发的体验会好很多，分页表格、表单校验、弹窗提示这些交互，Element Plus都有成熟组件，拖出来就能用。

不过前后端分离也意味着你要处理跨域问题。开发阶段最简单的方式是后端写一个配置类，放行所有跨域请求，我通常会在WebMvcConfigurer里重写addCorsMappings方法：

@Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowCredentials(true) .maxAge(3600); }

这段配置在后端开发阶段是够用的，实际部署到生产环境还是建议用Nginx做统一反向代理，同源访问就不存在跨域问题了。

对大多数做毕设项目的同学，我的倾向是：如果系统功能点偏展示型，用Vue + Element Plus做全套，视觉效果好；如果是偏功能型，用Thymeleaf就够了。这篇文的实操示例，我以Vue + Element Plus的前后端分离模式为准来讲，因为这套组合更贴近真实企业项目的形态。

3.3 项目初始化与基础配置

说点实际的搭建步骤。我用Spring Initializr生成项目的时候，依赖一般选这几个：

• Lombok：消灭实体类的Getter/Setter样板代码，@Data注解全搞定。
• Spring Web：构建RESTful接口。
• Spring Security：登录认证和权限管理。
• MyBatis-Flex或者MyBatis-Plus（如果用Flex，去Maven仓库自己搜最新坐标）。
• MySQL Driver：数据库驱动。
• Validation：后端参数校验。

生成项目后，第一件事是配application.yml。多环境配置一定要从一开始就分好，开发环境和生产环境的数据库连接、日志级别都不同，用spring.profiles.active来切换环境。

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/evaluation_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

map-underscore-to-camel-case: true这个是驼峰映射开关，数据库字段student_name能自动映射到Java属性studentName，一定要开。logic-delete-field配合全局逻辑删除配置，删除操作自动转成update set deleted = 1，数据不会物理消失。

如果你在自己电脑上跑MySQL，建议用Docker起一个实例，比本机装省心得多。一条命令的事：

docker run -d --name mysql8 -p 3306:3306 -e MYSQL_ROOT_PASSWORD=123456 -e MYSQL_DATABASE=evaluation_system mysql:8.0

我见过太多同学在环境安装上花掉半天，Docker这种方式五分钟就能把数据库拉起来，值得养成习惯。

4. 核心业务模块的实现细节

4.1 登录认证与JWT令牌机制

整个系统所有功能都是从登录开始的。我用的方案是Spring Security + JWT，简单说流程就是：用户提交账号密码，后端验证通过后生成一个带有效期的Token字符串返回给前端，前端把Token存在本地存储中，后续每次请求都在Header里带上Authorization: Bearer <token>，后端过滤器校验Token合法后再放行请求。

JWT由三部分组成：Header、Payload、Signature。Payload里我一般放userId、username、role以及过期时间exp。Service层生成Token的代码大致长这样：

public String generateToken(LoginUser loginUser) { Map<String, Object> claims = new HashMap<>(); claims.put("userId", loginUser.getUserId()); claims.put("role", loginUser.getRole()); return Jwts.builder() .setClaims(claims) .setSubject(loginUser.getUsername()) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 4)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }

这里有一个关键点，SECRET_KEY一定要放到配置文件里，写上足够长的随机字符串，不要硬编码在代码里。过期时间我设了4小时，这是多数课堂演示项目的常见值，实际生产环境可以根据系统使用频率调整。

依靠JWT，Spring Security的配置也要配合改。传统Session模式下的登录页跳转、Session管理都不适用了，我需要自定义一个OncePerRequestFilter，在每个请求进来时从Header里取Token，解析成功就把它放到SecurityContext里，让后续的@PreAuthorize注解能拿到当前用户身份。核心拦截逻辑：

@Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String header = request.getHeader("Authorization"); if (StringUtils.hasText(header) && header.startsWith("Bearer ")) { String token = header.substring(7); try { Claims claims = JwtUtil.parseToken(token); String username = claims.getSubject(); String role = (String) claims.get("role"); // 组装认证信息并放入SecurityContext } catch (Exception e) { response.setStatus(401); return; } } chain.doFilter(request, response); }

一个常见的坑是前端为了方便把Token存在localStorage里，这在XSS面前是不安全的。这个安全风险如果在毕设里讲出来，面试官反而会觉得你想过生产环境的问题，是加分项。

4.2 学生信息管理：批量导入的实现与易错点

学生信息管理模块看起来简单，不过是怎么把几千名学生的信息导进系统的问题。手动一条一条录入不现实，实际开发中都是靠Excel批量导入。

后端接收上传的Excel文件，用EasyExcel解析，逐行校验，校验通过后批量插入数据库。这条链路里有两个容易踩的坑我重点说。

第一个是Excel表头设计。模板里的列名要和代码里实体类的映射保持一致，不然解析出来全是空值。我建议用EasyExcel的注解方式直接映射，模板列就叫“学号、姓名、班级”，而不是让学生照着英文表头填：

public class StudentImportDTO { @ExcelProperty("学号") private String studentNo; @ExcelProperty("姓名") private String studentName; @ExcelProperty("班级") private String className; }

第二个是班级名称转班级ID。模板里填写的是“计算机2201班”，数据库里存的是班级表的自增ID，解析的时候要做一步查询替换。导入前可以先把班级列表查出来构建一个Map，避免每条记录都去查一次数据库，几千条数据的话性能差距非常明显。可以做一个预校验，在真正写库之前把Excel里的所有班级名一次性查出来，MISS的班级名返回给前端标记为错误行。

还有一点需要强调：批量插入不要用循环单条INSERT，改用MyBatis-Plus提供的批量插入能力效率高得多。实测几千条学生的导入，单条插入要几十秒，批量插入只用一两秒。

4.3 评定指标的动态配置：怎么设计才算灵活

评定指标模块好做，但要做灵活就有讲究。先说一个反面案例，有的同学把指标项和权重写死在数据库的某张表里，每学期规则一变就改代码，这是坚决要避免的。

我采用的设计允许管理员在界面上动态维护指标：

public class EvaluationIndicator { private Long id; private String indicatorName; // 指标名称，如“志愿服务” private Long categoryId; // 所属维度，如“社会实践” private Integer maxScore; // 满分值 private Double weight; // 权重系数，如0.2 private Integer sortOrder; // 展示顺序 private Integer status; // 启用状态 1启用 0停用 }

这里要和批次关联起来用的。一个批次对应一套指标配置，不同批次的权重、指标项可以是各自独立的。我单独建一张batch_indicator关联表，存批次ID、指标ID、权重、满分值。这样管理一个批次的时候，复制上一批次的配置，改几个数值就能投入使用，历史评定数据又不会受新配置影响——因为你关联的指标配置是当时的快照，而不是实时读取当前定义的。

动态配置的核心价值在于适配差异化场景。比如体育特长生评优时竞赛奖项的权重高一些，普通学生的重点在学业成绩。这些差异都通过配置解决，不靠写死代码分支，才是系统的合理走向。

权重计算的逻辑也得说清楚。每个维度的总分是各指标得分乘以权重后的累加，而综合总分是所有维度累加后的结果。举个例子，某学生“学业成绩”维度下的“主修课程平均分”指标是90分，“创新创业”维度下的“学科竞赛获奖”指标是85分，学业成绩维度权重0.4，创新创业维度权重0.3，那么这两项的初步贡献值是90×0.4=36和85×0.3=25.5，再补充其他维度后汇总成综合测评总分。实现这部分并不需要复杂算法，就是两层循环取配置项计算累加，但细节处需要留意：得分不能超过满分值，权重和必须等于1，否则排名口径就会有偏差。

4.4 材料审核流程：状态机设计是关键

材料审核模块是整个系统里业务流程最重的部分。一条学生上传的证明材料，会经历多个状态：待审核、审核通过、被驳回、已撤回。这几个状态之间是有严格转换关系的，不是所有状态都能跳。

这里我用了简单的状态机来管理，在代码层面用状态枚举定义合法的转换：

public enum MaterialStatus { PENDING(0, "待审核"), APPROVED(1, "审核通过"), REJECTED(2, "已驳回"), WITHDRAWN(3, "已撤回"); public boolean canTransitTo(MaterialStatus target) { switch (this) { case PENDING: return target == APPROVED || target == REJECTED || target == WITHDRAWN; case REJECTED: return target == PENDING; // 学生修改后重新提交 default: return false; } } }

这个状态机的价值体现得很直接。比如一个“审核通过”的记录，学生不能悄悄撤回重传，必须走管理员撤销的流程；“已驳回”的材料，学生只有一条路可走——修改后重新提交，状态转回“待审核”。这些规则写死在转换逻辑里，就不需要每个接口各自做一堆if-else判断了。

审核通过后还有个连锁动作要考虑。某些维度的得分要等材料通过之后才生效计入总分，例如“竞赛获奖加分”必须依据获奖证书通过审核来确认。所以材料审核通过要有一个联动逻辑：审核通过之后，自动读取出这条材料对应的得分值，计入该学生的评定总分中，或者在最终汇总时只统计那些“审核通过”的材料加分，这是评分时容易遗漏的隐性需求。

4.5 综合评定的计算逻辑与排名实现

打分计算模块是查成绩和排名的最终出口。多评委打分模式意味着一个学生可能被多个老师评，也可能按维度分不同老师评。比如辅导员评“思想品德”，班导师评“学业成绩”，各自互不干扰。

这个模块的关键设计点是评分的隔离性。一个评委打分的时候只能看到分配到他的学生和指标，看不到其他人的分数。这块实现不复杂，就是查询条件带上evaluator_id过滤，但刚上手的人容易在设计表结构时漏掉这个字段，后面再做就麻烦了。

我的打分表设计是这样的：

public class ScoreRecord { private Long id; private Long batchId; // 批次ID private Long studentId; // 被评学生 private Long evaluatorId; // 评分教师 private Long indicatorId; // 指标项 private BigDecimal score; // 得分 private String remark; // 评语 private LocalDateTime createTime; }

这个结构有一个好处：一条记录对应一个评委对一个学生的某一个指标的一次打分，数据粒度足够细，不会出现多个老师的分数字段挤在一个表里互相覆盖的情况。得分汇总的SQL也很直接：

SELECT student_id, SUM(CASE WHEN indicator_id = 1 THEN score * weight END) AS moral_score, SUM(CASE WHEN indicator_id = 2 THEN score * weight END) AS academic_score, SUM(score * weight) AS total_score FROM score_record JOIN batch_indicator ON score_record.indicator_id = batch_indicator.indicator_id WHERE batch_id = #{batchId} GROUP BY student_id ORDER BY total_score DESC;

排名结果出来之后，要写入一张单独的成绩汇总表，而不是每次查询时现场计算。理由很简单：评优结果要公示七天，期间可能会有评委修正某条分数。如果每次拉排名都实时算，结果就是动态的，公示数据变了却很隐蔽。正确做法是：指标分数全部审核完成后，后台执行一次“计算并固化排名”操作，把结果快照存储在ranking_result表，公示页面只读快照。等公示结束、成绩确认，再解锁生成最终报表。

这个思路就是典型的“结果固化”，在实际项目管理里很常见。做这类系统不要觉得实时计算很酷，大多数业务场景要的是稳定可解释的结果。

4.6 公示申诉：确保评审结果经得起质询

评优最忌讳的就是“暗箱操作”的质疑。就算分数都是真实的，没有申诉和反馈渠道，学生心里也难免犯嘀咕。所以我在系统里加入了公示与申诉模块，做完一轮评定之后，管理员可以在后台一键开启公示。公示状态下，学生对排名有异议可以发起申诉，申诉记录进入管理员的待办事项，处理完在系统里留痕，全程可追溯。

这一块技术上不复杂，无非就是一张appeal表加两个接口——学生提交申诉、管理员处理申诉。容易忽略的是申诉的时间窗口设计和状态同步。公示期外，学生的申诉按钮应该是禁用的，这个判断要在后端做，不能只在前端隐藏按钮，否则有人可以直接调接口绕过限制。

5. 开发过程中的常见问题与排查技巧

5.1 数据库相关：编码与连接问题

我在这类项目上遇到最多的问题，集中在数据库层面。

第一个是中文乱码。MySQL 8默认字符集是utf8mb4，但如果你是从旧库导入的数据，很可能建表时指定的是latin1。排查办法很直接，查看建表语句确认字符集，不符合的话用ALTER TABLE xxx CONVERT TO CHARACTER SET utf8mb4;转换。连接URL里也要带上characterEncoding=utf8，这是老生常谈但确实高频。

第二个是数据库连接失败。docker run的MySQL容器，本地Java程序连不上，多半是没写端口映射或者MySQL初始化还在进行中。用Docker的话，-p 3306:3306一定要写对，连之前先看容器日志，确认数据库就绪。

第三个是关于时区。MySQL 8默认时区不是北京时间，如果连接URL不带serverTimezone=Asia/Shanghai，就会报时间相关的异常。我推荐直接按前面的配置写好，不要在出问题的时候再去查，浪费时间。

5.2 Spring Security的配置雷区

Spring Security的坑主要集中在一件事上：误拦截放行的路径。

因为整个系统里有部分接口是不需要登录就能访问的——比如登录接口本身、验证码接口。我在写Security配置时，一定要把白名单路径显式列出来：

http.authorizeHttpRequests() .requestMatchers("/api/auth/login", "/api/auth/captcha").permitAll() .anyRequest().authenticated();

这里容易犯的错误是配了permitAll但还是被拦截，原因通常是配置顺序不对，或者anyRequest().authenticated()把前面所有规则又盖住了。Spring Security的匹配规则是从上往下，一旦某个请求匹配上了permitAll，就不会再往下走，所以白名单一定要写在前面。

还有一个容易忽略的地方，Spring Security 5之后对CSRF的保护默认是开启的，前后端分离模式下POST请求很容易被401拦截。开发阶段最简单的处理是在配置里显式关掉CSRF，因为使用JWT做无状态认证本身就不依赖Session的CSRF防护机制。

http.csrf().disable();

不少同学在这个问题上卡了很长时间，搭好接口一测试，GET能通，POST全挂，第一反应以为是自己代码写错了，其实多半是CSRF没关。

5.3 常见问题速查表

这些排查方向看着简单，但每一项背后都是实打实的踩坑经历。建议你遇到类似问题时先按表格逐条排除，不要一头扎进业务代码里Debug，往往问题出在配置层面而不是逻辑层面。

5.4 跨域配置与本地联调

最后再讲一个我调试时踩过好几遍的坑。前后端分离开发的时候，前端跑在localhost:5173，后端跑在8080，Axios请求一发出浏览器就给你拦截了——跨域。

解决方案就是前面贴过的addCorsMappings配置。但有三个细节要注意：

第一，allowCredentials(true)和allowedOriginPatterns("*")要同时使用，如果只用allowedOrigins("*")会报错，因为带凭证的请求不允许通配源。这个区分很微妙，Spring Boot 2.4版本之后用allowedOriginPatterns解决。

第二，浏览器还会发一个OPTIONS预检请求，配置里一定要放行OPTIONS方法，不然POST请求永远发不出去。

第三，开发完部署的时候，前端打包成静态文件丢到Nginx下，配置反向代理到后端同一域名，就不存在跨域了。这部分面试时能讲出来，说明你不是只会写业务代码的，理解部署链路。

6. 项目打包部署与后续扩展

6.1 Spring Boot项目的打包与部署

系统开发完成后，部署是最后一公里。Spring Boot项目打jar包非常简洁：

mvn clean package -DskipTests

打完的jar在target目录下，通过java -jar target/evaluation-system-0.0.1-SNAPSHOT.jar就能跑起来。如果你服务器上内存吃紧，可以通过-Xmx512m限制堆内存，不过我还是建议至少要给到1G，因为Spring Boot + MySQL组合起来内存占用不低。

部署的常见做法是：服务器装Nginx作为Web服务器，静态资源让Nginx处理，请求转发到Spring Boot进程：

server { listen 80; server_name your-domain.com; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这样应用只有一条访问路径，前端静态资源、后端接口、上传的文件都统一走Nginx，不用处理跨域问题，也方便后续配置HTTPS证书。

6.2 功能扩展方向：让项目更有竞争力

如果这个系统要拿去做毕业答辩或者面试作品，我建议在现有基础上扩展三个方向。

第一，接入消息通知。评优流程的每个关键节点都发通知——评价批次开启、材料被驳回、打分完成、排名公示。可以是站内信，进阶一点接邮件接口。这一块代码量不大，但能显著提升系统的完成度。

第二，接入数据可视化。排名结果出来后，用图表展示各班级的分数分布、各维度的平均分对比、历年评优数据趋势。后端给个聚合接口，前端用ECharts渲染，视觉上立刻提升一个档次。

第三，导出功能升级。除了简单导出Excel，可以加一个PDF评优证书生成功能。公示期结束，一键生成带学生姓名、奖项等级的电子证书，直接下载。这个需求在很多学校是实际存在的，做出来会让人觉得你想得非常周全。

这些扩展本质上都是现有模块的延伸，骨架没变，增量也不大，却能极大提升项目完整度和答辩可讲的故事量。

我个人在实际开发这类管理系统时体会最深的一点是：业务系统的复杂度从来不在技术，而在于对流程的理解。先把评优评定的业务流程跑通画清楚，再动手建表写代码，你会发现每一张表、每一个接口都有据可依。反过来，如果一上来就急着写代码，做到一半往往又要回头改表结构，那才叫真正的折磨。