每年三四月份，教务处的微信消息基本就被各种Excel表格刷屏：交题目汇总表、收学生选题表、统计开题报告提交情况、排答辩分组。我用Spring Boot做了一套毕业设计管理系统，内部立项编号11374，最初就是为了解决这个混乱。系统覆盖学生、教师、教学秘书三类核心角色，把选题、开题、中期、论文提交、答辩评分整条流程全部串了起来。所有环节的状态实时可查，材料统一归档，成绩自动折算，再也用不着到处收集表格。这篇文章不打算只讲CRUD怎么写，而是把从需求分析、技术选型、数据库设计、核心模块实现，到实际开发踩坑、答辩演示准备的完整过程都拉出来复盘一遍。准备用Spring Boot做毕设或者做教务管理类项目的同学，可以拿这篇当一个端到端参考，少走不少弯路。
1. 毕设系统（11374）的定位：教学管理的真实痛点
1.1 毕业设计流程中的角色与业务节点
先看毕业设计这件事到底涉及到多少人、多少环节。很多人一开始就把系统想简单了，觉得无非是"学生传论文，老师打分数"，但实际跑一遍流程会发现，参与方至少是四类：
- 学生：浏览课题、提交选题意愿、上传开题报告、中期检查表、论文定稿，查看成绩。
- 指导教师：发布课题、审核学生选题、审阅各阶段材料、给出修改意见和评语。
- 专业负责人：审核教师发布的课题是否合规，监控专业内选题完成率。
- 教学秘书/管理员：维护学年学期参数、导入学生名单、编排答辩组、录入最终成绩、导出各类统计报表。
如果只做一个"论文上传"的功能，那系统根本没有解决任何核心矛盾。11374项目的重点不在材料本身，而在流程。出题、审核、选题、确认、开题、中期、论文评阅、答辩、归档，每个环节之间都是强依赖关系：学生没选题成功就不能交开题报告，教师没审核通过就不能进入下一阶段。用Excel管这套流程的痛处我列在下面这张表里。
| 角色 | 常见痛点 | 系统对应能力 |
|---|---|---|
| 学生 | 不知道选题结果是否被确定、材料交到谁手里 | 选题状态实时查看，材料提交有截止时间提醒 |
| 教师 | 邮箱微信收材料，版本混乱，漏看消息 | 统一待办中心，按阶段审阅材料并留痕 |
| 专业负责人 | 题目质量没法把关，重复选题多 | 题目审核环节，按专业维度统计 |
| 教学秘书 | 汇总表格耗时，答辩分组费劲，成绩核算易错 | 自动分组，成绩自动按权重折算并支持导出 |
1.2 功能边界：毕设系统不能什么都做
需求阶段往往是最容易失控的。11374的第一版需求清单有57条，我最后砍到了不到30条。砍掉的标准就两条：第一，这件事用Excel勉强能应付，又不强制留痕的，不做；第二，跟毕业设计主流程无关的锦上添花功能，不做。比如有人提过要做站内即时聊天、要做在线文档多人协同编辑，这些虽然听起来唬人，但既偏离流程管理这个核心，又会把开发周期拖到答辩前夜。
系统真正的核心是三个词：流程、状态、归档。流程指节点必须按顺序推进；状态指任何一条数据在任何时刻都能说清楚"走到哪一步了"；归档指每个环节的材料都有统一存储位置，不用再翻聊天记录。把边界划清楚之后，开发才可能聚焦。
1.3 核心功能模块总览
11374最终落地的功能模块可以分成六块：
- 用户与权限模块：学生、教师、专业负责人、管理员四种角色，登录后显示各自的待办看板。
- 课题管理模块：教师发布课题、填写题目描述/要求/人数上限，专业负责人审核。
- 选题与流程模块：学生提交选题志愿，教师确认或驳回，系统维护整个状态机。
- 材料提交模块：开题报告、中期检查、论文定稿按阶段上传，超过截止时间自动锁定。
- 答辩与评分模块：教学秘书编排答辩组和场次，答辩组长录入答辩分，系统自动折算总分。
- 统计与导出模块：按专业、班级、导师统计进度，一键导出Excel成绩表和选题名单。
这套模块设计本身不复杂，但每一步业务状态怎么流转、数据怎么落库，才是真正决定项目质量的地方。
2. 技术选型复盘：为什么是Spring Boot加Vue前后端分离
2.1 Spring Boot为什么是毕业设计系统首选
11374后端选Spring Boot，核心考虑不是"流行"，而是三个实际原因。
第一，自动装配把配置成本压到了极低。传统SSH时代写一个数据源要配一堆XML，Spring Boot用起步依赖加约定优于配置的方式，一个spring-boot-starter-web就把MVC、内嵌Tomcat、JSON序列化全部带进来了。@EnableAutoConfiguration会读取META-INF/spring.factories或AutoConfiguration.imports里的自动配置类，再通过@ConditionalOnClass、@ConditionalOnMissingBean这类条件注解按需生效。开发时你只管加依赖、写配置，剩下的交给框架。
第二，生态成熟，踩坑成本低。MyBatis-Plus、Redis、EasyExcel、MinIO这些常用的组件都有Spring Boot官方或社区starter，版本兼容问题提前被过滤了一遍。对学生来说，遇到问题随手搜一下基本都能找到方案，这一点对毕业设计尤其重要——你不可能花大量时间在冷门框架的底层排查上。
第三，答辩场景的现实考量。Spring Boot是当前教学和市面上用得最广的Java框架，答辩老师即便自己不写，也大概率能看懂项目结构。选择技术栈有时候不光是技术问题，也是沟通问题。
| 对比项 | SSH | SSM | Spring Boot |
|---|---|---|---|
| 配置方式 | 大量XML | XML+注解混用 | 注解为主，自动配置 |
| 部署 | 需要外置Tomcat | 外置Tomcat | 内嵌容器，jar直接跑 |
| 学习曲线 | 陡峭 | 中等 | 平缓 |
| 社区资料量 | 少 | 一般 | 极多 |
2.2 ORM选型：MyBatis-Plus而不是JPA
ORM层我用了MyBatis-Plus，没有用Spring Data JPA。不是说JPA不好，是在毕业设计这个场景下，MyBatis-Plus更合适。
MyBatis-Plus的优点很直接：BaseMapper自带增删改查，单表CRUD一行都不写SQL；分页有内置插件；动态SQL用@Select注解或者XML都能写，复杂的多表关联查询完全可控。JPA的@Entity映射和派生查询确实省事，但一旦遇到动态条件多的统计报表，要么写@Query大段JPQL，要么就要小心N+1查询问题。对经验不那么多的人来说，SQL可控意味着出问题的时候你能肉眼排查。
实践下来，11374项目里80%的查询都是单表条件查询，MyBatis-Plus的QueryWrapper足够对付，剩下的多表统计用XML手写SQL也没花多少时间。唯一要注意的是，QueryWrapper这种链式条件多了之后，代码会变得很"散"，建议复杂条件统一封装到Mapper的XML里，service层只做业务编排。
2.3 辅助组件：Redis、MinIO、EasyExcel各管什么
- Redis：负责登录验证码、数据字典、以及热门课题的访问计数。这些数据特点是读取频繁、允许偶尔延迟，放数据库也能跑，但放Redis里响应快得多，也顺便演示了缓存的用法。
- MinIO：负责论文PDF、开题报告、中期检查表这些文件对象。之所以不用服务器本地目录，是因为本地文件在打包部署、容器重启时很容易丢失，而且不便统一管理权限。MinIO走S3协议，内网部署一套非常轻量。
- EasyExcel：负责导出选题名单、成绩汇总表。
@ExcelProperty注解配一个实体类就能导出，避免用POI手动写单元格样式，代码量能省一个量级。
2.4 前后端分离模式下的跨域问题
前端选了Vue 3加Element Plus，打包后由Nginx托管，后端独立部署，访问通过/api前缀转发。开发环境下前端跑在8080端口，后端跑在8081端口，必然要处理跨域。
最简单的方式是在后端写一个全局CorsFilter，注意前端如果用了withCredentials: true，这和后端允许的origin不能写成*。下面这段配置是11374项目里实际使用的：
@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOrigin("http://localhost:8080"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }等部署到线上之后，前端页面和后端接口都走同一个域名，Nginx把/api反向代理到后端，生产环境其实就不再依赖这个Filter了。所以建议开发环境和生产环境分开配置，生产用Nginx代理顺带把跨域问题一并消掉。
3. 从空项目到可运行骨架的搭建细节
3.1 版本选择：Spring Boot 2.7还是3.x
开发环境用IDEA，JDK版本1.8，Spring Boot选了2.7.x，没有上3.x。选择理由很实际：Spring Boot 3必须JDK 17起步，虽然新特性多，但MyBatis-Plus、Knife4j这类组件在老版本上兼容性更稳，网上能查到的资料也绝大多数基于2.x。对毕业设计来说，"稳"远比"新"重要。如果非要折腾3.x，光javax.*到jakarta.*的命名空间迁移就够喝一壶的，没必要在答辩前给自己找事。
IDEA新建项目时，依赖只需要勾四个起步：
- Spring Web
- MySQL Driver
- Lombok
- Spring Boot DevTools
MyBatis-Plus、Redis、MinIO的依赖后面在pom.xml里手工加，版本号统一用<dependencyManagement>管理，避免传递依赖打架。
3.2 分包结构与命名规范
包结构直接决定了后台上手速度。11374的分包如下：
com.campus.grad ├── common // Result统一返回、全局异常、工具类 ├── config // CorsConfig、RedisConfig、MybatisPlusConfig ├── controller // 接口层 ├── service // 业务层，接口+Impl ├── mapper // MyBatis-Plus Mapper接口 ├── entity // 数据库实体 ├── dto // 接收前端参数的对象 └── vo // 返回前端视图的对象有一个经验值得分享：参数校验要放在service层而不是controller层。controller保持轻薄，只负责参数绑定和结果返回；业务规则比如"学生只能选三个志愿"这种必须放在service里校验，否则将来加一个定时任务或者管理员代操作，很容易绕过校验逻辑。
3.3 application.yml中容易出错的配置项
application.yml是整个项目配置的重灾区，我把11374里踩过的关键配置贴出来：
server: port: 8081 spring: datasource: url: jdbc:mysql://localhost:3306/grad_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 servlet: multipart: max-file-size: 50MB max-request-size: 100MB mybatis-plus: mapper-locations: classpath:/mapper/**/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl knife4j: enable: true几个坑提前说。MySQL连接串里必须带serverTimezone=Asia/Shanghai，否则默认时区导致时间字段差8小时。allowPublicKeyRetrieval=true是MySQL 8.x连接时经常遇到的坑，不加上去会报Public Key Retrieval错误。文件上传大小限制要按实际需求调，默认只有1MB，论文PDF动不动几十MB，不配好就直接报MaxUploadSizeExceededException。
3.4 数据库核心表设计与选题状态机
11374的数据库叫grad_system，核心表不多，但所有业务都围着它们转：
- sys_user：用户表，角色字段区分学生/教师/专业负责人/管理员。
- topic：课题表，关联教师ID、专业、人数上限、当前已选人数、审核状态。
- topic_selection：选题记录表，关联学生ID、课题ID、志愿顺序、审核进度。
- process_report：过程材料表，阶段类型开题/中期/论文定稿，文件地址、审核意见。
- defense_group：答辩组表，关联成员、地点、时间段。
- score_record：评分表，记录各环节得分、教师评语。
最核心的设计是选题状态机。课题本身有四种状态：0草稿、1待审核、2审核通过、3已驳回。选题记录有三种状态：0待教师确认、1已通过、2已拒绝。我没有用字符串存状态，统一用int，再在代码里定义一个枚举类。字符串状态最大的问题是随心所欲，你永远想不到后来的人会填一个"Passed"还是一个"已通过"，用枚举收敛之后就安全得多了。
表之间也没有到处用外键，只有逻辑关联。原因很简单，毕业设计系统数据量不大，外键的强一致性在这里意义有限，反而会给导入数据、定时清理增加麻烦。学生名单每年要重新导入，如果没按顺序插数据，外键约束会让人抓狂。
4. 核心业务实现：选题、流程流转与文件归档的落地
4.1 选题并发冲突：多个学生同时抢一个课题
选题开放那天晚上，才是系统真正接受考验的时候。学生不会平均分散在一天里操作，基本集中在晚上十点到十二点。热门课题名额八个，可能一下子涌进来二十个人同时选。如果直接select判断人数再insert，并发情况下必然超卖。
我用的是条件更新方案。选题表topic上维护一个selected_count和max_count，学生选题时执行下面这条SQL：
UPDATE topic SET selected_count = selected_count + 1 WHERE id = #{topicId} AND selected_count < max_count影响行数为1说明抢到名额，为0说明已经满员。这一步操作在数据库层面是原子的，不需要锁和事务配合就能解决超卖问题。配合topic_selection表的student_id + topic_id唯一索引，保证一个学生不能对同一个课题重复提交，整个并发问题就收住了。
4.2 权限控制与状态流转
四种角色的接口权限我用了一个自定义注解加拦截器实现，没有引入Spring Security。毕业设计的权限模型简单，用Spring Security配置一大堆过滤链反而重，自定义拦截器三行就能搞定。
@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { String[] value(); }在拦截器里取当前登录用户的角色，判断是否在注解允许的范围内。状态流转的合法性校验放service层统一处理，比如"选题确认"方法里先判断topic_selection.status是否为0，不是就抛业务异常。核心原则是：所有修改状态的入口都走同一个service方法，绝不允许多个地方都能随意改状态，否则状态机很快就会烂成一团。
4.3 文件上传与MinIO对象存储
论文和过程材料走MinIO。后端封装了一个FileStorageService，对外只暴露upload和presignedUrl两个方法：
- 上传时生成UUID文件名，避免中文名和重名导致的路径混乱，文件原始信息单独存到数据库。
- 下载时不直接公开桶的读权限，而是生成带有效期的预签名URL，过期自动失效，答辩完成后权限自然回收。
MinIO的endpoint要特别注意。开发环境用http://localhost:9000，部署环境如果内网访问就用内网IP，不要图省事在浏览器里先测通了https://play.min.io就直接抄进配置，那个公共演示环境根本不适合生产使用。
4.4 答辩评分与成绩自动折算
答辩结束之后，教学秘书最怕的是手动算成绩。11374里成绩分三部分：指导教师分占40%、评阅人分占30%、答辩组评分占30%。score_record表里记录原始分，统计时按权重自动折算，再结合学生阶段材料的完成情况得出最终结果，导出成Excel。
导出这块强烈建议用EasyExcel，文档里写一个实体类加@ExcelProperty("姓名")注解，一行代码就能把数据写到流里面。用传统POI手写单元格样式，几百行代码起步，真心不划算。
5. 开发中实测踩过的五个坑与完整排查链路
5.1 启动报"Failed to configure a DataSource: 'url' attribute is not specified"
这是Spring Boot新手出镜率最高的报错。现象很诡异：application.yml里明明写了数据源配置，启动还是报这个错。排查链路分享给你们：
第一步，先看@SpringBootApplication所在的位置。Spring Boot默认扫描启动类所在的包及其子包，如果把启动类放在了com.campus，而配置文件放在com.campus.grad.config下面没被扫描到，配置就不会自动生效。第二步，检查resources目录是否被IDEA正确识别成资源目录，target/classes里如果没有编译出来的application.yml，那跑的就是一个没有配置的项目。第三步，再确认yml文件缩进，spring.datasource是两层缩进，经常有人把url写到跟spring同一层，这种错误肉眼非常难发现。
真实场景里90%是这个三类问题，不要一上来就往@ConfigurationProperties绑定上想。
5.2 时间字段前后端差了8小时
系统上线第一天，学生提交的开题报告在列表里显示的时间全部少了8小时。排查链路是这样的：先看数据库里的created_at，发现存储时间没问题，排除MySQL写入问题。再看后端JSON序列化返回的时间，发现接口返回的已经是正确的时间字符串，排除Java时间对象问题。最后在前端页面打印拿到的数据，发现浏览器解析的时候把时间当成了UTC时间，默认转成了本地时区。
解决方案是三层同步处理：MySQL连接串加serverTimezone=Asia/Shanghai，Spring Boot配置文件里设置Jackson的时区：
spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8前端展示时统一用dayjs的dayjs(value).format('YYYY-MM-DD HH:mm:ss')格式化。三层都到位之后，时间再也没错过。
5.3 跨域"通了又没通"的诡异现象
开发时遇到一个非常恼火的问题：接口能正常返回数据，但浏览器控制台仍然报CORS错误。查了半天发现，是拦截器在CorsFilter之前抛了异常。异常一旦被全局异常处理器捕获，响应头就丢了CORS相关字段，浏览器直接拒绝解析响应。
这个事的教训是：如果你在DispatcherServlet层面加了自定义拦截器，一定要保证CorsFilter在过滤器链上排在拦截器前面，而且全局异常处理时不丢弃已有的响应头。Spring Boot里把CorsConfig那套写好，配合@Order(Ordered.HIGHEST_PRECEDENCE)注册，基本能规避。
5.4 MinIO上传时偶尔报错：The difference between the request time and the current time is too large
这个坑花了我一个晚上。现象是上传偶尔失败，报请求时间和当前时间差太大。排查链路：公司/学校内网如果部署了NTP时间同步服务，某台服务器的系统时间如果掉了，客户端和MinIO服务端时间差超过15分钟就会拒绝请求。
解决方式很简单，在MinIO服务端所在机器上校准系统时间，并加入定时时间同步。这个问题的隐蔽性在于，问题不出在代码逻辑，也不出在存储本身，纯粹是环境的时间漂移。
5.5 部署后文件全变成0KB：临时目录的幽灵
本地开发一切正常，jar包丢到服务器上之后，学生上传的附件全部是0KB。排查之后发现，Spring Boot默认会把上传的临时文件写到/tmp/tomcat.*目录，服务器做了定期清理，或者磁盘空间不够，文件在写入过程中就丢了。
解决办法是配置spring.servlet.multipart.location，把上传临时目录显式指定到项目的数据目录，比如/data/grad-system/upload-tmp，并且保证该目录有足够空间。顺带建议，上传的文件一定要最终转移进MinIO，不要直接留在临时目录。
5.6 源码丢了：Spring Boot jar包怎么反编译成项目
热搜里有一条"怎么将springboot jar反编译成项目"，这个确实也是不少人的亲身教训。如果源码意外丢失，只剩部署的jar包，可以用IDEA自带的反编译功能快速恢复。把jar包拖进IDEA，反编译出来的class就能看到源码内容，用于找回大部分逻辑是可行的。如果class文件较多，推荐用CFR这个命令行工具批量反编译，再手工整理成工程结构。
但我的真实体会是，反编译只能救急，注释注释没了、泛型信息会有一定丢失、构建配置也得重新补。真正靠谱的做法是第一天就把代码推到Git仓库，哪怕一开始只有一行README，也比事后反编译强百倍。
6. 让程序在答辩时"加分"的小细节
6.1 接口文档直接上Knife4j
很多毕设项目做完了，接口有哪些自己都说不清。我用Knife4j自动生成接口文档，配合@ApiOperation("学生提交选题志愿")这类注解，答辩演示的时候打开/doc.html，所有接口一目了然。评委老师想看你系统做了什么，不用在页面上一个个点，接口文档平铺开，反而显得项目更专业。
6.2 全局异常处理与统一返回结构
11374里所有接口统一返回Result<T>结构，包含code、message、data三个字段。业务异常通过BusinessException抛出，由@RestControllerAdvice统一捕获并转成对应的Result。这样做的好处是前端处理错误逻辑非常统一，不再需要针对每个接口做判断，也对将来扩展拦截器、定时任务很有帮助。
代码建议单独加一个AOP切面统计接口耗时，把超过1秒的慢请求打日志，答辩的时候如果老师问到性能优化，你可以直接拿出日志说哪几个接口慢、怎么优化的。这个细节经常能救场。
6.3 演示数据与演示路径设计
答辩现场最容易翻车的是网络和数据准备。演示前我专门准备了三个账号：管理员、教师、学生，各自对应一套预置数据。为了不被弱网拖累，我提前把常用接口的数据在Redis里预热一遍，冷启动之后第一次点击也是秒开。强烈建议不要现场注册账号、不要现场上传大文件，这些操作务必提前做好，把演示时间压缩到展示核心业务逻辑上。
6.4 README与一键部署脚本
项目根目录放一份结构清晰的README，包含技术栈、模块说明、数据库初始化脚本、环境要求和启动步骤。同时写了一个deploy.sh脚本，一条命令完成打包、停止旧服务、启动新服务。这些文档和脚本本身不算功能，但能让评委快速看懂整个项目，体现出的工程习惯比多写一个模块加分更明显。
做完这套系统，我最深的体会是：技术选型和代码技巧固然重要，但毕业设计系统这类管理项目真正值钱的地方在于流程建模。你把Excel里那种"群里喊一嗓子问进度"的模式抽象成状态机，让每条数据都能明确回答现在在哪一步、下一步该干什么，这个系统就已经成功了一大半。最后分享一个答辩演示的小技巧：演示前把浏览器缓存清理干净，提前把系统冷启动跑一次让缓存热起来，展示的时候你会明显感觉到比现场手忙脚乱从容得多。项目代码建议当天就推到Git仓库，后面的路会顺畅很多。
