基于SpringBoot的高校毕业设计管理系统：从数据库到答辩全流程设计

每到毕业季，教务办公室里最忙的往往不是答辩现场，而是答辩前后的材料整理和流程跟进：老师要反复提醒学生交任务书、开题报告、中期检查表，学生要四处打听课题审核到哪一步，教务员则天天对着十几个 Excel 表格核对"谁还没提交、谁格式不对、谁该进二辩"。我最初接手这个基于 SpringBoot 的高校毕业设计管理系统时，以为只是一个普通的 CRUD 项目，真把需求梳理完才发现，它涉及教师申报课题、学生选题、任务书下达、开题审核、中期检查、论文定稿、评阅、答辩评分、成绩归档这一整条长链路。对打算拿它当毕业论文题目，或者给学校做信息化项目的开发者来说，这篇文章应该能帮你少走不少弯路。

这个系统的核心价值，是把"课题与答辩"这条跨学期的主线流程全部搬到线上。哪些角色在什么时间能做什么事，哪些数据必须留痕，成绩由哪些环节按什么权重汇总，都需要提前设计清楚。我采用的是 SpringBoot + MySQL 的经典 Java Web 技术栈，前端做成了前后端分离结构。下面我从需求拆解、数据库设计、后端实现、问题排查这几个维度完整复盘一遍。

1. 先看清需求：毕业设计全流程到底要管哪些事

1.1 高校业务侧的真实痛点

在动手码代码之前，我跟着教务老师跑了一整天流程，最后整理出来的痛点有那么几条：

• 课题信息分散。老师用 Word、微信、邮件报课题，教务员需要人工汇总，容易出现重题、超人数、信息缺失。
• 状态不透明。学生选没选上课题、开题报告审核通过没有，只能去问老师，缺少一个统一可见的进度关系。
• 过程材料收集困难。任务书、开题报告、中期进展、论文终稿，每一轮都要收集、打包、命名规范五花八门。
• 答辩数据统计低效。答辩分组名单、成绩录入、最终综合成绩折算，多数靠手工，极容易算错权重。

所以这个系统本质上不是给人 "填表" 的，而是要对齐"计划、执行、检查、归档"这一串动作。想清楚这一层，功能列表才不会被做成简单的公告板加文件上传。

1.2 角色与边界：四类用户，而不是三类

最初很多同学设计管理系统只想到管理员、老师、学生三种角色，真正做起来你会发现还需要第四类角色：评阅人或答辩专家。教务人员和答辩专家虽然在数据上不一定需要独立的账号体系，但业务流程上必须有明确区分。

我最终把角色收敛成这么五类：

• 系统管理员：维护基础数据、开设毕业设计批次、配置流程节点、管理答辩分组和归档数据。
• 教师：负责课题申报、审核学生的选题申请、下达任务书、对开题和中期材料进行审核评价、参与评阅打分。
• 学生：浏览课题库、填报选题志愿、按节点上传各类文档、查看审核结果。
• 答辩组长 / 组员：在指定答辩组内给学生现场评分，填写答辩评语。
• 教务员（可选）：通常是管理员的一个子集，只具备查看统计和导出的权限。

角色边界清晰之后，菜单、接口、数据权限就都有了依据。这也是后面做 JWT 登录鉴权和菜单动态加载的基础。

1.3 技术选型：为什么是 SpringBoot + MySQL

这套系统在当时的选择逻辑很直接：团队熟悉 Java，学校机房和服务器普遍还是 JDK 8 环境。SpringBoot 2.7.x 是一个长期维护且兼容 JDK 8 的稳定版本，对做毕业设计或中小型教务系统来说足够稳妥。

版本这块提醒一点：Spring Boot 3.x 起步要求 JDK 17，如果部署环境是旧服务器，可能会遇到各种兼容问题。网上很多人问"springboot 版本太高怎么办"，大多就是因为本机装了新版但部署机 JDK 还是 8。我的建议是需求优先，稳定优先，没有虚拟线程和 GraalVM 之类的强诉求，不需要盲目追新。

ORM 最终选了 MyBatis-Plus，原因是这类管理系统里单表 CRUD 比例很高，它能省掉不少重复的 Mapper 方法。数据库用 MySQL 5.7/8.0 都可，注意建表统一使用 InnoDB 引擎和 utf8mb4 字符集，不然遇到生僻字或表情符号会出现乱码。

2. 数据库设计：表结构拆不好，后面全是补丁

2.1 核心表是怎么拆出来的

我不建议直接照抄开源项目的表结构，因为业务流程不一样。我当时是沿着"一条毕业设计记录从诞生到归档要经历什么"来拆表的。

基础数据层有三张表：用户表（统一账号）、学生信息扩展表、教师信息扩展表。账号体系一旦统一，登录、权限、批量导入都会省事很多。

业务主体层则围绕"一个课题从申报到归档"建模。最核心的几张表如下：

特别注意 t_select_record 这张表，它是学生和课题之间的多对多关联。设计中我让学生可以填第