基于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 这张表，它是学生和课题之间的多对多关联。设计中我让学生可以填第一志愿和第二志愿，但最终只允许有一条记录进入"已通过"状态。这个约束不能只靠 Java 代码判断，数据库层面也要把 (student_id, status) 做唯一索引，保证数据不会因为并发操作而乱掉。

选题记录表唯一索引可以这样定义：

sql复制CREATE UNIQUE INDEX uk_student_active
ON t_select_record(student_id, status);

这里有个小细节：MySQL 唯一索引默认把 NULL 当作不同值，所以状态字段建议默认给一个数字，比如 0 表示待审核、1 表示确认通过，而不是让未处理状态为 NULL。

2.2 状态字段到底该怎么设计

流程型系统最忌讳字段混乱。一开始有人建议用 status 字段 + update_time 一个字段解决问题，后面发现根本没法追溯"什么时候被谁打回、为什么打回"。

我最终在每个业务表里都放了两类字段：

• 当前状态字段：只保留当前所处节点，比如 audit_status。
• 扩展流程记录表：记录每一次状态变更动作，谁操作、何时操作、操作前状态、操作后状态、批注内容。

一次选题审核，学生提交申请时 insert 一条记录；导师审核通过时再 insert 一条状态流转记录。系统里随时能画出完整时间轴。

主题模块的状态机大致如下：

text复制草稿(0) -> 待审核(1) -> 已通过(2)
              └--------> 已打回(3) -> 编辑后重新提交 -> 待审核(1)

打回之后允许重新编辑并再次提交，这是最常见的闭环。如果你在状态字段上只是简单做几个常量，没有统一的状态流转控制，业务逻辑最终会写成一堆 if/else，后期基本没法维护。

2.3 状态流转的并发风险

做这类系统第二个容易翻车的地方是"同一时间多人操作同一状态"。比如学生在选题，老师同时也在审核；如果选题人数只剩最后一个名额，两个学生同时提交，后端查了 selected_count < max_students，结果两个都通过，就会超出上限。

我的解决办法有两个，配合使用：

第一，扣减名额采用原子更新，不用先查再改：

sql复制UPDATE t_title
SET selected_count = selected_count + 1
WHERE id = #{titleId}
  AND selected_count < #{maxStudents}

只有当更新的影响行数是 1 时，才真正说明这个学生抢占成功。

第二，在 t_select_record 上针对同一学生的活动记录建唯一索引。即使两个人同时提交，也会有一个在插入时触发 DuplicateKeyException，然后回滚事务并给出友好提示。

这套实现比引入 Redis 分布式锁轻量得多，也够用。高校一个毕业设计批次撑死几千学生，高性能锁在这里属于过度设计，还会增加项目复杂度。

3. SpringBoot 后端落地：项目结构和关键代码

3.1 后端目录结构怎么分层

如果项目一开始就堆一堆 Controller，后面加功能就是灾难。我习惯按下面这种方式分层，既能支撑毕业设计论文里的"经典三层架构"描述，也能满足实际扩展：

text复制src/main/java/com/example/graduation
├── common          // 统一返回结果、异常处理、常量
├── config          // WebMvcConfig、拦截器、文件上传配置
├── controller      // 接口层
├── service         // 业务层
├── mapper          // 数据访问层
├── entity          // 数据库实体
├── dto             // 入参对象
├── vo              // 出参对象，避免直接返回实体
└── utils           // 工具方法

业务层不要为了"少写代码"就把所有判断堆在 Controller 里。我一般会把"选题""审核""提交答辩成绩"这类关键动作放到 Service，并且加上事务。

3.2 核心业务：选题审核的 Service 实现

我拿选题审核举一个例子。老师端审核学生选题时，后端核心流程包括：判断课题状态是否为待审核、判断教师是否有权限审核、更新选题记录状态、写入审核日志。这几个动作必须在一个事务里完成。

java复制@Service
public class SelectRecordServiceImpl extends ServiceImpl<SelectRecordMapper, SelectRecord> {

    @Resource
    private TitleService titleService;

    @Resource
    private ProcessLogService processLogService;

    @Override
    @Transactional(rollbackFor = Exception.class)
    public void auditSelect(Long teacherId, Long selectId, Integer auditStatus, String remark) {
        SelectRecord record = this.getById(selectId);
        if (record == null) {
            throw new ServiceException("选题记录不存在");
        }

        Title title = titleService.getById(record.getTitleId());
        if (title == null || !title.getTeacherId().equals(teacherId)) {
            throw new ServiceException("无权审核该课题");
        }

        // 只有处于待审核状态的记录才允许审核
        if (!SelectStatus.PENDING.getCode().equals(record.getStatus())) {
            throw new ServiceException("该记录当前不能被审核");
        }

        // 审核前先原子扣减名额，防止超选
        if (auditStatus.equals(SelectStatus.APPROVED.getCode())) {
            int rows = titleService.increaseSelectedCount(title.getId(), title.getMaxStudents());
            if (rows == 0) {
                throw new ServiceException("课题名额已满，操作失败");
            }
        }

        record.setStatus(auditStatus);
        record.setAuditComment(remark);
        record.setAuditTime(new Date());
        this.updateById(record);

        // 记录一条操作日志
        processLogService.addLog("select_record", record.getId(),
                "审核选题", teacherId, "待审核", auditStatus.toString(), remark);
    }
}

这个代码里最关键的是先做状态判断再做更新，并且把状态判断放进事务里统一处理。很多人写的代码会先查状态，在 Controller 层判断结束后就开始写库，中间一旦出现并发，状态就不可信了。

Controller 层不要直接操作实体对象，我通常用一个 VO 返回给前端，避免把数据库内部字段暴露出去。

3.3 文件上传与下载：最容易翻车的模块

毕业设计里最重的文件就是论文正文，动辄几十 MB。文件上传模块的核心配置是：

yaml复制spring:
  servlet:
    multipart:
      max-file-size: 200MB
      max-request-size: 200MB

光是改这个还不够，还要解决文件名问题。学生交上来的文件经常是"毕业设计（最终版）（1）.docx"这种名字，直接保存会造成中文乱码，而且多人交同名文件还会互相覆盖。

我的做法是：物理文件名使用 UUID 随机生成，例如 20250612-8f3a2c9d.pdf，原始文件名单独存到 original_name 字段里。下载时再把原始文件名回传给前端，这样既不丢文件名信息，又避免了存储层乱码。

上传接口裁剪后的逻辑大致是：

java复制@PostMapping("/upload")
public R<String> uploadDocument(@RequestParam("file") MultipartFile file,
                                @RequestParam Long studentId,
                                @RequestParam String businessType) {
    if (file.isEmpty()) {
        return R.fail("上传文件不能为空");
    }
    String originalFilename = file.getOriginalFilename();
    if (StringUtils.isBlank(originalFilename)) {
        originalFilename = "未命名文件";
    }
    String ext = StringUtils.substringAfterLast(originalFilename, ".");
    String storeName = UUID.randomUUID().toString().replace("-", "")
            + "." + ext;

    // 存储到自定义目录，而不是项目 resources 下
    String uploadDir = fileStorageProperties.getUploadDir();
    File dest = new File(uploadDir + File.separator + storeName);
    file.transferTo(dest);

    DocumentRecord doc = new DocumentRecord();
    doc.setStudentId(studentId);
    doc.setBusinessType(businessType);
    doc.setOriginalName(originalFilename);
    doc.setFileUrl("/file/download?fileName=" + storeName);
    doc.setVersionNo(nextVersion(studentId, businessType));
    documentRecordService.save(doc);

    return R.ok(doc.getId());
}

注意一点：不要把上传目录放在项目的 src/main/resources/static 下。一来重新打包部署会把已上传文件清掉，二来权限控制也不好做。我习惯把上传目录配置成外部路径，比如 /data/graduation/upload，部署时通过 application.yml 指向这个目录。如果业务中后续要扩展多服务器共用文件，也可以方便地迁移到 MinIO 或云对象存储。

4. 前端交互与权限控制：系统好不好用的关键

4.1 模板渲染还是前后端分离

如果完全用 JSP 或 Thymeleaf 写，问题不大，但毕业设计管理系统页面多、角色多，前后端耦合在一起会增加后期维护成本。我这里选择的是 SpringBoot 提供 JSON 接口，前端用 Vue.js + Element UI 实现，前端构建出静态文件后部署到 Nginx，后端只关心 API。这样做的好处是接口可以单独测试，前端也能独立复用。

早期 Java Web 项目常见的就是 jsp + jQuery，如果你是在已有老项目上加功能，jQuery 完全够用。但如果是新开项目，想引入 vue-element-admin 这类现成模板，前后端分离会更顺手。这套系统的登录请求、选题提交、审核操作都是标准 REST 风格接口，接 Vue 不需要额外处理。

4.2 登录鉴权：用 JWT 还是 Session

毕业设计管理系统不需要引入太重的 SSO 体系，我建议用 JWT + 拦截器。登录成功后签发 token，前端把 token 存到 localStorage 或者 pinia 里，每次请求在 header 带上 Authorization: Bearer xxx。

后端配置一个拦截器做统一校验：

java复制@Component
public class AuthInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 放行登录接口和文件预览接口
        String uri = request.getRequestURI();
        if (isWhiteList(uri)) {
            return true;
        }

        String token = request.getHeader("Authorization");
        if (StringUtils.isBlank(token)) {
            throw new ServiceException(401, "未登录或登录已过期");
        }

        // 解析 token 后把当前用户放到 ThreadLocal
        Long userId = JwtUtil.parseToken(token.replace("Bearer ", ""));
        UserContext.setUserId(userId);
        return true;
    }
}

拦截器里特别要注意把 /login、/file/download、/doc/preview 这类接口放行，否则钉钉预览或者浏览器直接打开文件链接都会 401。

角色权限如果用 Spring Security + 注解也可以，但更多时候前端只需要知道两个信息：当前用户的角色 code 和可访问的菜单列表。所以登录接口的返回体我会包含用户信息和 permissionList，前端路由根据权限动态生成。若想再严格一些，也可以在关键按钮上做后端校验，比如非教师角色调用课题申报接口直接返回 403。

4.3 三个核心交互节点怎么做

• 课题申报：教师端是一个带富文本编辑器的表单，填写完成提交后课题进入待审核状态。导师可以随时撤回修改，但一旦被管理员审核通过，课题就锁定，不能直接改。这是为了避免学生已经选了课题后题目内容悄悄变化。
• 选题窗口：管理员在后台配置"选课开始时间"和"选课截止时间"，时间未到或已过，都不能提交志愿。学生端可以查看每个课题的剩余名额。名额实时显示是后端返回了 selected_count 和 max_students，不需要 WebSocket 实时推送，查询频率完全够用。
• 答辩评分：答辩组长登录后，只看到本组学生列表。每条学生记录后有一个"去评分"按钮，点击后进入评分表单。评完分之后成绩可以保留在草稿状态，答辩全部结束后再统一提交上传，防止填错无法回退。

答辩评分还有一个容易忽略的点：一个答辩组通常有多位评委，同一学生要被评多次。最终成绩需要按预设权重取平均分。t_score 表里我用 scorer_id 区分是谁打的分，再通过 score_type 区分是"教师评阅分"还是"答辩现场分"。最后成绩汇总时按类型分别取平均，再乘权重相加，公式写在后台配置里，前端只负责展示。

5. 常见问题与避坑实录

5.1 文件上传大小限制和目录问题

很多开发者部署后遇到上传报 MaxUploadSizeExceededException，第一反应是检查 Nginx 的 client_max_body_size，结果后端 SpringBoot 也限制了，两边都要调。如果用了 Nginx 反代，必须同时改：

nginx复制client_max_body_size 200m;

否则用户上传 100MB 的论文时，Nginx 先返回 413，压根到不了后端。调试时可以同时看 Nginx 的 error.log 和 SpringBoot 的日志，确定是哪一端拦截的。

目录问题再补一刀：如果用 IDE 直接启动项目，相对路径 ./upload 指向的是项目根目录；用 jar 包启动时，./upload 则指向 jar 所在目录。路径不一致会导致本地能上传、部署后上传文件找不到。最好的办法是在配置里设置绝对路径：upload-dir: /data/graduation/upload，启动前预先创建目录。

5.2 SpringBoot 版本和依赖冲突

有时候并不是你的代码有问题，而是依赖版本打架。比如引入了高版本 MyBatis-Plus，它内部依赖的 mybatis-spring 版本和当前 SpringBoot 不兼容，启动就报 Invalid value type for attribute 'factoryBeanObjectType'。

这种问题多半出在 MyBatis-Plus 版本和 Spring Boot 3.x 组合时。如果用 SpringBoot 2.7.x，选 MyBatis-Plus 3.5.3 以下比较稳；用 SpringBoot 3.x 时，则要选对应适配版本。别小看这件小事，我见过有人因为这个报错卡了两天，最后把 SpringBoot 版本降回去反而一下就通了。

另一个高频问题是循环依赖。Spring Boot 2.6 开始默认禁止循环依赖，如果你的 Service A 和 Service B 互相 new，启动会直接报错。解决办法是重构结构，而不是加 @Lazy 糊弄过去。在业务上，课题服务和选题服务天然是上下层关系，正确的做法是把"满员校验+名额扣减"放到课题服务里，让选题服务单向调用课题服务即可。

5.3 时间类型返回格式不一致

数据库时间字段是 datetime，实体用 java.util.Date，接口返回给前端时经常会变成时间戳数字，或者差 8 小时。原因是 JSON 序列化时没有指定时区。

在 application.yml 里加上一段配置就能解决：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

如果项目里个别字段要返回日期不返回时间，可以在字段上面加 @JsonFormat(pattern = "yyyy-MM-dd", timezone = "GMT+8")。做成绩归档和选课时间窗口时，时间边界特别重要，比方说某课题报名截止到 2025-04-30 23:59:59，如果没有统一时区，前端看到的时间会偏差 8 小时，非常容易引发学生投诉。

5.4 答辩成绩的不可重复提交

老师在前端连续点两次"提交成绩"，如果后端没有做幂等处理，就会产生两条评分记录。系统提示只能评一次，数据库里却多了一条。

处理办法很简单：在 t_score 表上建唯一索引，用 (student_id, scorer_id, score_type) 三个字段做唯一约束。新增记录时先查一次，再保存一次，就算并发来了，第二次插入也会因唯一索引失败。同时后端捕获 DuplicateKeyException 后转成友好提示“不可重复评分”，而不是返回 500 错误。

这里进一步说明为什么我坚持记录过程日志。成绩提交应该有完整的痕记录，每次修改谁改的、改前多少分、改后多少分都留在日志表里。答辩成绩一旦归档，原则上不再允许随意修改；如果有争议要调整，管理员也是走"打回成绩"的操作，系统自动留痕，而不是直接改数据库。

答辩成绩的格式校验也是个值得多写几笔的地方。我给每一项评分都设置了范围区间，比如开题评分满分 100，现场答辩评分满分 100，但是系统最终综合成绩可能是百分制，也可能是五级制。评委填写的分数必须在前端做一次数字范围校验，后端再做一次。后端的校验不能省，因为总有人绕过前端直接 POST 接口。数据进库前把脏数据拦截住，比后面再去清洗要省太多时间。

我个人的经验是，这类管理系统能不能真正在高校落地，核心不在于用了多新的技术，而在于流程是否完整、状态是否清晰、数据是否能追溯。前端再漂亮，如果状态流转是混乱的，教务员用一个月就会放弃。先梳理业务，再写代码，这个顺序在任何流程型系统里都不会错。

如果你正准备拿这个题目做毕业设计，有一个建议送给你：不要只盯着"选题"和"答辩"两个高光节点，把任务书、开题、中期检查这些过程节点做扎实，反而更容易体现出你系统设计的完整性。把基础表结构里的流程日志表和文档版本设计好，这就是你答辩时最大的亮点之一。

最后再分享一个小技巧：开发时不要把流程的开始和结束做死。用配置项或字典表管理每个流程节点的开关，例如"当前是否允许学生提交开题报告"。这样即使学校临时调整安排，你只需要改数据库配置，不用改代码重新部署。这一点通常也是答辩老师最容易感兴趣的地方。