SpringBoot+Vue+MyBatis毕业设计管理系统实战：从设计到部署

1. 这个毕设项目到底在做什么

先聊点实在的。每年到了毕业季，计算机相关专业的学生基本都会撞上同一个需求：毕业设计管理系统。这个东西听起来很行政化，但只要你用过一次就知道，它解决的是高校里一个非常真实的痛点——论文选题靠抢、指导记录靠微信、中期检查靠催、成绩汇总靠Excel。作为一个做过不少类似管理系统的开发者，我可以负责任地讲，这类题目年年有人做，年年都有人翻车。

翻车的原因通常不是写不出代码，而是没想清楚这个系统到底服务谁、流程是怎么走的、哪些模块是必须有的、哪些是做出来给自己挖坑的。

先说这个项目标题里的关键词：SpringBoot、Vue、Java、MySQL、MyBatis，配置非常经典，是当前Java全栈开发里最稳定的组合之一。SpringBoot负责后端接口与业务逻辑，MyBatis负责和MySQL打交道，Vue负责前端页面渲染，Java跨平台运行环境兜底。这套技术栈最大的好处是资料多、社区成熟、网上能搜到的踩坑记录也很多，特别适合毕业设计这种既要工作量又要稳定性的场景。

再说项目的业务价值。毕业设计管理系统看起来只是把线下流程搬到线上，但本质上它把四类角色塞进了同一套系统：学生需要选题、交开题报告、提交论文初稿终稿、查看老师意见；老师需要发布课题、审核学生选题、填写指导记录、打分；教研室或院系管理员需要管理师生账号、分配双选、控制时间窗口、统计最终成绩；系统管理员维护的基础数据包括院系、专业、班级、用户角色。这些角色一旦理清楚，系统的菜单和权限基本就确定了。

我见过不少同学拿到这类源码之后，直接跑起来就往数据库里灌测试数据，然后截图写论文。这么干虽然能过，但答辩时老师一问“这个字段怎么设计的”“这个表为什么这么拆”，当场容易卡壳。所以这篇文章我不会只讲怎么把项目跑起来，我会从数据库设计、后端接口、前端页面到部署上线，把整个系统的设计思路和实现细节串一遍。无论你是想把这个项目作为自己的毕设底子，还是单纯想学一下完整项目的落地方式，这篇文都能给你一个可以直接抄作业的参考。

同时我也想把话说清楚：这类系统本身不存在多高的技术难点，真正的难点在于业务流程是否闭环、异常情况是否处理到位、代码结构是否经得起追问。能把这三点讲明白，比单纯贴一堆代码更有价值。

2. 整体设计与技术选型的思路复盘

2.1 为什么是SpringBoot+MyBatis而不是其他组合

后端框架这块，Java生态里其实有两条主流路线：一条是SpringBoot+MyBatis，另一条是SpringBoot+JPA/Hibernate。我见过很多同学在选型时纠结，这里直接说我的判断：毕设场景下，SpringBoot+MyBatis更合适。

原因是MyBatis把SQL控制权完全交还给你。毕设答辩时，老师最喜欢追问的问题之一就是“你这个查询的SQL是怎么写的”，如果用的是MyBatis，你可以现场把Mapper里的SQL调出来讲，表关联、条件判断、分页逻辑一目了然。而JPA这类ORM框架自动生成的SQL比较抽象，真到要解释底层逻辑的时候反而麻烦。另外MyBatis对复杂查询的支持非常灵活，尤其是论文审核记录、选题统计这类需要多表关联加条件筛选的场景，写XML里的动态SQL比用JPA拼规格查询要直观得多。

SpringBoot这边也没什么好纠结的。它内置Tomcat，打jar包就能跑，不像传统SSM项目还要单独配置外部容器。加上它提供了大量的Starter依赖，一个坐标就能引入整套Web能力，开发体验非常顺。配合Lombok处理实体类getter和setter，项目代码量能压缩不少。

MySQL作为配套数据库同样务实。这类管理系统并没有海量数据和高并发诉求，MySQL完全扛得住，而且它的人工成本低：无论是本机安装还是用Docker跑一个实例，网上都有大把教程。更重要的是，面试和答辩中MySQL相关的问题很多，索引、事务隔离级别、SQL优化这些点如果能在毕设里用起来讲清楚，非常加分。

2.2 技术版本怎么定：说一个最容易翻车的细节

版本这件事很多人不当回事，但它恰恰是我见过翻车率最高的一块。

SpringBoot版本和JDK版本必须匹配，这是第一原则。比如SpringBoot 3.x要求JDK 17以上，而不少学校机房或老师的习惯环境还停留在JDK 8。如果你写项目时用了SpringBoot 3.x，到答辩现场发现机器上只装了JDK 8，项目起不来，场面会非常尴尬。

我个人的建议方案是：JDK 1.8 + SpringBoot 2.7.x + MyBatis Spring Boot Starter 2.3.x + MySQL 5.7或8.0。这套组合经过大量实践检验，兼容性最好，网上能查到的资料也最丰富。等你真正把系统跑通了，再考虑升级SpringBoot 3.x也不迟，但毕设阶段没有必要为一个新版本特性去冒险。

Vue这边同样有版本选择问题。Vue 2和Vue 3的生态差别不小，如果你的前端代码基于Vue 2，Element UI组件库用得很顺手，那就别强行升级Vue 3。反过来，如果刚学前端不久，建议直接上Vue 3 + Element Plus，因为Vue 2已经停止维护。拿到源码时务必先确认package.json里的vue版本和对应的UI组件库，不要因为版本对不上在依赖安装阶段就卡了一整天。

还有一点提醒：SpringBoot和Vue的端口要提前约定好。后端通常在8080，前端开发服务器在9528或5173，前后端分离联调时必须通过代理或后端开启CORS来解决跨域。如果代理配不好，浏览器里看到的就是一屏幕的跨域报错。这个细节下面会详细说。

2.3 角色、权限和状态的建模：先用用户故事把流程捋直

写代码前先把业务角色和各自操作梳理一遍，能避免后期大面积返工。

毕业设计管理系统的核心角色分为四种：管理员（教务或院系管理）、教师、学生，有时候还会拆出一个教研室主任用于审核课题，但大部分简化版系统里都由管理员代劳。角色不同，功能菜单和操作边界就不同。

我建议用表格把角色-功能矩阵列出来，再动手建表写代码：

状态机设计是另一个容易出问题的地方。一个学生的选题申请，至少要经历“待审核—审核通过/驳回—确认选题—已定题”这么几个状态；一篇论文，通常包括开题报告、初稿、终稿等不同阶段，每个阶段都有提交和审核两种操作。如果数据库里只用一列int类型表示状态，很容易在代码里写出一堆魔法数字，维护起来很难受。我个人更推荐用字符串类型保存状态，后端定义常量或枚举统一管理，可读性会好很多，后期答辩展示代码时也更容易讲明白。

拿论文提交模块举个例子：一张提交记录表里应该有论文阶段、状态、原始文件名、存储路径、提交时间、批注意见、评阅分数等多个字段。有些同学用布尔型字段表示“是否通过”，看起来简洁，但没法表达“退回修改”这种中间状态。倒不如让状态字段支持pending、approved、rejected、resubmitted这些语义化值，配合后端枚举类做校验，流程上能灵活不少。

3. 数据库设计：把表拆清楚，全项目就成功了一半

3.1 核心数据表的结构与关系

从建表开始说。毕设管理系统的数据库通常包含这样几张核心表：用户表（包含学生、教师、管理员统一账号）、学生信息表、教师信息表、课题表、选题记录表、指导记录表、论文提交记录表、成绩表。这里我给出简化的建表思路，你可以根据自己的需求调整字段。

用户表的设计建议单独抽出来，不要用“学生表、教师表”各存一套登录账号。用一个user表保存登录凭证，再通过用户类型字段区分角色，同时用profile_id关联扩展信息表。这样做的优势很明显：登录逻辑只需要写一套，管理员维护账号时也只需要维护这一张表的记录。

课题表是系统的核心数据源，字段通常包括课题名称、课题类型、来源类型（真题真做/自拟）、所属方向、简介内容、要求描述、计划人数、已选人数、发布状态、教师ID、发布时间。如果希望对课题做更细的管理，还需要一个审核字段：教师发布的课题是否允许学生看到，日常可以由管理员把关。

选题记录和课题表之间是一对多关系：同一个课题被多个学生选择就会产生多条选题记录，但每条记录自己带状态。后端在受理选课时，要写一个事务方法：先检查课题当前已选人数是否达到上限，再检查学生是否已有被选中的记录，最后才插入一条待审核的申请记录并在课题表上的已选人数加一。

导师指导记录是这类系统里很容易被弱化的模块。有的源码里直接没有，或者只做成了一个纯文本框保存。实际上这个模块是指导老师日常使用频率最高的，也最能体现系统业务完整性。一张指导记录表至少应该包含记录内容、记录时间、下次任务安排、学生ID、教师ID、课题ID。如果想做得好一点，可以在学生提交论文和老师填写指导记录之间建立关联：老师看到学生提交的新版本后写指导记录，学生也可以随时查看历史记录。

论文提交表通常和用户表、课题表关联，记录每次上传的文件路径、版本号、阶段类型、说明信息。这里要特别注意：不要用一个文件路径字段反复覆盖。正确设计是保留历史版本，每条提交记录独立存在，在界面上展示版本编号，老师评阅时能直接对比不同版本。

最后说成绩表。毕业设计的最终成绩不建议只存一个总分。学校通常会拆成开题答辩成绩、中期检查成绩、论文评阅成绩、最终答辩成绩，最后按权重加权汇总。所以建议在score表里给每个分项留字段，算出综合分后再落一个字段。后续做统计报表时，这种字段设计会轻松很多。

3.2 关于索引、时间字段和逻辑删除的取舍

核心查询场景务必建索引，否则数据量上来后接口响应会肉眼可见地变慢。课题表的教师ID、选题记录表中的学生ID和课题ID、成绩表中的课题ID和用户ID，这些字段因为要频繁参与where条件、join关联或分组统计，都应该加普通索引。索引不是越多越好，表数据量小、写操作频繁的字段就完全不需要索引。

时间字段建议统一使用datetime类型：创建时间、更新时间可以让数据库自动维护，也就是DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP。如果你使用MyBatis Plus这类增强框架，它内置的自动填充功能更好用，加个注解，插入和更新时自动帮你填充，不用每张表写重复代码。

逻辑删除可以说是MyBatis生态里一个高频考点。用deleted字段标记数据是否删除，可以避免物理删除之后历史记录断链，但也容易踩坑：不加条件的count会把你删掉的数据也算进来，关联查询时忘了加“deleted = 0”条件很容易查出已经逻辑删除的脏数据。在毕设系统里，我建议只对少量核心业务表做逻辑删除，比如课题表——管理员误操作撤销课题后要把数据恢复回来。对指导记录、日志这类追加型数据表，直接物理删除或只做时间归档就行了，别为所有表统一套用逻辑删除。

3.3 初始化数据脚本和测试账号

写完建表语句后，需要顺手准备一份数据初始化脚本，里面包括管理员账号、若干教师和学生测试账号、几条课题样例数据。在写账号密码时有个常见手法：数据库中不能存明文密码，至少要使用MD5加盐哪怕还不够推荐，毕设里也可以用BCrypt做密码哈希。

如果你拿到的源码里自带了SQL文件，记得看它里面初始化账号的密码校验规则。有些学习资料里的默认密码是123456，但加密规则使用的是不可逆算法，你不知道原始明文就没办法登录。遇到这种情况，比较稳妥的做法是用代码里的密码编码器手动生成一条新的加密密码，把用户表里的对应记录update掉，再拿自己设定的明文去登录。

让我给你一份可供参考的建表SQL片段，讲清楚核心字段的注释和思路：

sql复制CREATE TABLE `user` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `username` varchar(50) NOT NULL COMMENT '登录账号',
  `password` varchar(100) NOT NULL COMMENT '加密后的密码',
  `real_name` varchar(50) DEFAULT NULL COMMENT '姓名',
  `role` varchar(20) NOT NULL COMMENT '角色: admin/teacher/student',
  `profile_id` bigint(20) DEFAULT NULL COMMENT '关联扩展信息表ID',
  `status` tinyint(4) DEFAULT '1' COMMENT '账号状态: 1正常 0禁用',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户账号表';

这段SQL里值得注意的地方：username设置了唯一索引，避免注册时产生两个相同账号；role字段直接存字符串，不用数字映射，查看数据时能少一层心智负担；profile_id设计成多态关联的方式，让它既可能指向student_info表的记录，也可能指向teacher_info表的记录。这个设计在答辩时是一个非常值得展开讲的知识点——有一种专门的设计模式叫多态关联，在类似广告位、评论对象这种边界不固定的业务场景中非常实用。

课题表的建表语句里，可以给状态加一个约束：写入或更新记录时，状态必须在合法枚举值范围之内，防止程序传脏数据进库。示例片段：

sql复制`status` varchar(20) NOT NULL DEFAULT 'UNPUBLISHED'

这里用UNPUBLISHED表示未发布，PUBLISHED表示已发布，ENDED表示已结束。状态的可读性比纯数字好太多。但需要注意后端服务启动时，在项目初始化代码里完成状态校验，否则存了非法值自己也不知道。

4. 后端接口与业务逻辑的实现要点

4.1 接口RESTful风格与统一返回结果

用SpringBoot写接口时，建议从第一天起就定义一个统一的Result类，所有controller方法的返回值都是它。这个类至少包含code、message、data三个字段。code为200时表示成功，其他值对应各类业务异常。这样做的好处是前端可以统一拦截处理：请求成功取data渲染页面，请求失败弹message提示，代码逻辑非常清爽。

很多开源框架里会直接用org.springframework.http.ResponseEntity作为返回值，配合HTTP状态码驱动流程，这当然也行。但从前后端约定和代码可读性角度考虑，我更喜欢业务接口统一返回200，业务状态放在Result的code字段里处理。前端拿到200之后用code来决定跳转还是提示，逻辑更直观。

接口路径命名应该遵循RESTful风格。比如课题管理：

plaintext复制GET    /api/topics         分页查询课题
POST   /api/topics         新增课题
PUT    /api/topics/{id}    修改课题
DELETE /api/topics/{id}    删除课题
GET    /api/topics/{id}    查询课题详情
POST   /api/topics/{id}/select    学生选题

这里很多人容易忽略的一步是：新增和修改对应的请求体使用场景不同。新增时后端生成创建时间，修改时只更新部分字段。建议将新增对象和更新对象拆分成不同的DTO，不要直接使用实体类接收前端传入的参数。直接使用实体类接收请求体比较容易暴露模糊的扩展字段，还会被Spring的自动绑定机制莫名其妙地填充不期望的数据。

4.2 MyBatis Mapper层：几个容易踩的坑

先聊MyBatis的常见配置。开发阶段需要在application.yml里把日志级别调成debug，并设置MyBatis的日志打印实现为StdOutImpl，这样控制台才能看到每次执行的SQL语句。等到项目部署到服务器时记得关掉，否则每张页面加载都会在后台打出一堆日志。

配置参考如下：

yaml复制mybatis:
  mapper-locations: classpath:mapper/*.xml
  type-aliases-package: com.example.entity
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
    map-underscore-to-camel-case: true

map-underscore-to-camel-case这个配置很关键。它能把数据库字段的下划线命名自动映射到Java类属性的驼峰命名，数据库design_teacher_id就能自动对应Java里的designTeacherId。不要小看这一行配置，漏了它的话你每写一个XML查询，都要手动给每个字段起一个别名，工作量非常折磨。

在写Mapper接口方法时，返回值类型要留意。查询列表应该返回List<实体类>，不能写成返回实体类，除非你确保结果只有一条。查询单条记录时如果没有匹配的数据，MyBatis会返回null，代码里获取结果引用前就要先判空再访问属性，否则会抛空指针。

还有个常见的坑是多参数方法。MyBatis对多参数的处理很特殊，如果你在Mapper接口里写了一个方法：

java复制List<Topic> selectByTeacherAndStatus(Long teacherId, String status);

那么对应的XML里，如果直接使用#{teacherId}会报错，提示参数找不到。原因是MyBatis默认会给参数起名为param1、param2，代码里要么用注解写@Param("teacherId")，要么在XML中引用param1。新手最容易在这上面浪费功夫，建议所有多参数Mapper方法都养成加@Param注解的习惯，从源头规避这个问题。

分页查询推荐使用PageHelper，它是MyBatis生态里非常成熟的分页插件。用法非常简单：查询前调用PageHelper.startPage(pageNum, pageSize)，紧接着执行那条Mapper查询方法就可以。分页获取到的结果被PageHelper包装成Page对象，包含了total总记录数，传给前端做分页组件渲染就够了。如果你用MyBatis Plus，它自带的分页插件也差不多，只是要记得注入PaginationInnerInterceptor才能生效，我第一次对接时漏了拦截器配置，分页老返回全量数据，排查了半天，最后发现是插件没有注册进去。

4.3 Service层事务与业务规则校验

Service层必须处理事务。选题、发布课题、提交论文这几个操作都涉及多张表的数据变更。以选题为例：学生提交选题申请后，需要向选题记录表插入申请记录，同时把课题表的已选人数加一，甚至是先锁定课题行数据防止并发超额。如果不加事务，这两步操作的任何一步失败，都会造成数据不一致，最直观的后果是课题已选人数对不上，学生在页面看到自己选了题，老师那边却查不到申请记录。

使用SpringBoot在业务方法上加@Transactional注解时，默认回滚规则只针对RuntimeException，运行期异常发生才会回滚。如果代码里手动catch住了异常，没有往外重新抛出，Spring事务代理感知不到异常发生，就默认提交了。正确的做法是：catch到业务异常后，先做一些清理或日志记录操作，再原样向上抛出运行异常，让事务能够正常回滚。

这部分有一个我认为值得多说的点：事务方法内部的代码不能自己调用自己。Spring事务是基于AOP代理实现的，当你在同一个类里用this调用另一个标注了@Transactional的方法时，代理模式根本不会介入，事务就不会生效。要解决就得把内部方法拆到另一个Service类里，或者自己注入自身代理。这种问题在日志里往往一点异常都不报，项目看似正常，实际做了一半的操作没回滚。答辩时如果老师问到了这个细节，你能答出来就非常亮眼。

校验业务规则的代码要放在Service层而不是Controller层。Controller不该直接参与业务逻辑，它只负责接收参数并调用Service方法，然后给前端返回统一结构。学生选题时先查询一下课题是否存在，再检查课题状态是否允许选，再数一数课题是否已满员，最后查一下当前学生有没有已经选定的课题，全都没问题再进行最终插入操作。这些规则放在Service层的设计，也让Controller层的代码能保持非常薄的状态，看起来清爽，也好维护。

4.4 权限控制方案的简单实现

毕业设计管理系统里做权限控制不一定要引入Spring Security或Shiro全套框架。虽然这两个框架功能完善，但学习成本和使用成本都不低，对毕设来说，我建议可以自己通过拦截器加注解做一个极简的权限方案。

在后端定义一个RoleRequired注解，然后在需要管理的Controller方法上标注允许访问的角色。拦截器拦截所有带有这个注解的方法，从当前请求的切入点获取用户信息，再判断当前用户角色是否在允许列表里。这样既保证了核心接口不会被未登录用户访问，也便于演示和代码讲解。

SpringBoot中可以通过HandlerInterceptor接口实现自定义拦截器：

java复制public class AuthInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        if (handler instanceof HandlerMethod) {
            HandlerMethod method = (HandlerMethod) handler;
            RoleRequired roleRequired = method.getMethodAnnotation(RoleRequired.class);
            if (roleRequired != null) {
                String currentRole = (String) request.getSession().getAttribute("currentRole");
                if (currentRole == null || !Arrays.asList(roleRequired.value()).contains(currentRole)) {
                    response.setStatus(401);
                    return false;
                }
            }
        }
        return true;
    }
}

再在配置类里注册这个拦截器并配置拦截路径。

java复制@Override
public void addInterceptors(InterceptorRegistry registry) {
    registry.addInterceptor(authInterceptor)
            .addPathPatterns("/api/**")
            .excludePathPatterns("/api/login", "/api/register");
}

这里需要注意一个细节:Session在前后端分离架构里默认不生效，因为浏览器发起跨域请求时不会自动携带cookie。如果项目基于前后端分离模式，通常有两条路：一个是项目整体同域部署，前端构建后的静态文件直接放在后端SpringBoot的resources/static目录中，Session机制天然可用；另一个是前端独立部署，则需要引入JWT令牌校验方式替代Session。毕设项目可以选第一种，把Vue打包后的文件放到后端项目里，通过同一个域名访问，联调阶段最省心，还能顺便回避掉一对跨域配置的麻烦。

5. Vue前端实现的关键路径

5.1 环境准备：装对Node版本再动手

前端环境是所有问题里最让人崩溃的一个环节。很多同学拿到Vue项目源码，第一步npm install就卡死或者疯狂报错。原因十有八九是Node.js版本与Vue CLI或者依赖包版本不兼容。

Vue 2项目建议使用Node 14或16版本，Vue 3项目建议使用Node 16或18版本。如果本机装的Node版本太高，比如Node 20以上跑Vue 2旧项目，经常会遇到OpenSSL相关的报错，提示“error:0308010C”，这是因为新版Node的哈希算法默认改成了OpenSSL 3，和webpack 4的旧算法不兼容。遇到这类情况时，一种方法是降低Node版本，另一种是用环境变量对Node算法做兼容切换。具体到实际命令行，有些项目会报“digital envelope routines”，需要把Node降到版本符合要求，这方面需要注意个人开发环境的变更。

安装依赖之前可以通过npm config set registry https://registry.npmmirror.com把npm源切换到国内镜像，会大幅提升依赖下载速度，这是我在所有项目里最优先执行的一条命令。如果软件源问题解决后完成项目依赖安装的时间还是太长，可以检查一下npm的缓存设置。

5.2 前端项目结构划分和路由设计

前端项目建议按模块划分目录，而不是把所有页面平铺在views目录里。一个清晰的前端目录能把组件的边界划得很干净，后期维护找文件都很方便。

plaintext复制src/
  api/            # 接口请求封装
  assets/         # 静态资源
  components/     # 公共组件
  router/         # 路由配置
  store/          # Vuex或Pinia状态管理
  views/
    login/        # 登录页面
    student/      # 学生端功能页面
    teacher/      # 教师端功能页面
    admin/        # 管理员端功能页面
  utils/
    request.js    # axios实例封装

路由设计的首要原则是根据角色动态生成。学生登录系统后只能看到课题库、我的选题、论文提交列表，教师登录后看到的是我的课题、待审核学生、答辩成绩管理菜单。管理员看到的更多，但也不可能让管理员进入学生的选题接口。

一种常用的实现方案叫做动态路由注册：登录成功后拿到当前用户的角色信息，根据角色在前端预先设置好的路由表映射中过滤出该角色允许访问的页面，再通过router.addRoutes方法注册，提交动态菜单。这种方法能够在菜单级别精准限制用户能看的内容，而且后续增加新页面，只需要在预先设置的路由映射表上更新一下就行。

路由和菜单这块，我特别乐于强调的一点是：后端接口也要做拦截，不能只做前端页面拦截。很多毕设项目前端隐藏了按钮或者路由，直接调用API，后端却没有任何权限校验，在操作日志里伪造请求就能访问教师接口了。如果答辩时老师问你这个安全隐患怎么解决，你不能只说“前端路由做了拦截”，要把后端的基于角色的权限校验方案也作为补充说明的方向。

axios请求封装我通常在项目里固定使用独立实例，配置一个统一的baseURL，开发环境走代理请求，避免直接写死localhost地址，生产环境也方便切换路径。我会在axios的请求拦截器里统一注入token凭证。响应拦截器统一判断HTTP状态码和后端业务码，遇到session过期的场景直接跳转到登录页，这会让前端的错误处理统一度变高。

5.3 核心页面的实现拆解：以选题双选与论文上传为例

课题选择页面是整个系统的核心交互场景。页面通常是一个分页表格，展示课题名称、类型、发布教师和已选人数。学生点击选课按钮后能否弹出二次确认，是一个非常推荐的细节。确认弹窗里还要实时显示“是否已经达到选题人数上限”的补充信息，如果不显示就会让用户发起无效请求。

这个页面的数据流是：进入页面时先调用分页搜索接口，拿到课题列表，后端返回的数据里包含了教师姓名或者课题类型的字典化处理。这些字段我建议后端直接返回已经格式化好的字符串，比如“导师姓名”，而不是返回teacherId，让前端再查一次教师信息表。这是开发中比较容易忽略的地方，往返通信在实现上会增加不少复杂度。

选题后进入“我的选题”页面，页面打开时先显示当前学生选题的状态。后端设计上可以公开一个查询学生当前选课状态的接口，返回null时表示还没有选择，否则返回状态和课题明细。依据状态的不同，页面给学生展示的行动按钮也会不同：待审核状态下不能再次提交新的申请，审核通过后确认定题，驳回后可以选择其他课题。

论文上传页面实现时有一个大坑，就是文件上传控件的默认行为。前端用Element UI的Upload组件时要把action设置为后端文件上传接口地址，但很多同学都忽略了headers携带token，每上传一次就被后端拦截一次，反手就是一个401。另外要关闭自动上传，让学生在选中文件之后点击“提交论文”按钮再正式发起动作，避免选了文件就自动传到服务端，带来文件管理上的混乱。

同时提醒一下，文件上传后端要设置合理大小限制。比如SpringBoot需要在application.yml里配置：

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

不放大会导致默认1MB限制，论文附带的压缩包传了一半就报错。做了这个限制以后，接口层面必须在异常处理器中捕获MaxUploadSizeExceededException，返回明确的中文提示，否则用户只会看到一道500异常页面，根本不知道该改小文件还是联系管理员。

5.4 Vue项目的打包发布方式

前端编译完成的最终一行命令是npm run build，构建完毕之后dist目录中出现完整的静态文件。毕设系统一般推荐把dist内的所有文件复制到SpringBoot项目的src/main/resources/static目录，再打包后端工程成一个可执行的jar文件。启动jar包后，浏览器直接访问http://服务器IP:8080就能打开系统。

集成部署最大的好处是不用单独安装Nginx或者专门的部署Node服务进程，也回避了跨域这一整套麻烦。虽然没有采用前端工程化领域里那种完全独立部署方案那么酷，但对大量零基础部署经验的毕设作者来说却是最稳妥的一条路。

6. 论文框架中值得展开讲解的模块：选题双选、指导过程与成绩评定

6.1 为什么额外讨论这些业务细节

很多开源的毕设项目把系统做成一个普通的增删改查框架：课题可增删，登录可查，数据一目了然。但在实际的高校毕业设计流程中，有一些操作细节体现了真正的业务能力和项目深度，比方说：选题是“双向选择”而不是学生直接自由抢占，教师看到的是“待审核申请的列表”而不是被动的申请堆满页面。指导过程会把每次交流的内容都留存下来，论文从开题到结束按版本评审、可对比，而不是一个简单的上传文件模块。最终总成绩由多个分项加权得到，这部分充分体现出项目能否在真实业务场景里落地。

如果想让系统在毕设答辩中拥有额外亮点，那么这三块至少要完整实现两块以上。

6.2 从“抢课”到“双选”：状态流转上的完整闭环

双选流程可以这样设计：教师发布课题后课题进入UNPUBLISHED状态，管理员审核通过后进入PUBLISHED状态。学生填写课题申请后，系统产生一条PENDING选题记录。教师引导学生筛选列表后，操作通过或者驳回该选题。若教师通过，学生端收到一个确认按钮，点击确认后选题记录变为CONFIRMED，至此课题也被标记成“已定题”，不能再被其他学生选择。有些学校还支持教师和学生互选阶段结束后由管理员统一批量安排，算法实现上可以做成轮询调度逻辑。

把状态机确定下来后，要对同一时期的边界情况做保护，保证学生的每个时刻只有一个有效选题。学生如果申请了一个课题但没有被任何教师处理就跑去申请另一个课题，数据库里就会产生多条PENDING记录。这个在真正的业务上是不合理的，后端可以在搜索可申请课题的接口上给出逻辑限制，学生只允许保留一个PENDING状态和一个CONFIRMED状态的课题记录。

关于状态变迁，我再补充一个实践建议：业务代码里不要到处用字符串比较来判断状态，建议在后端定义一个枚举类，把所有的合法性校验集中到一个静态方法里。比如TopicStatusEnum.handled(status)这类方法，写完再全项目复用，到后期代码重构时也能省大量时间。

6.3 论文版本、指导记录与成绩评定的联动

论文提交和指导记录产生的业务逻辑其实是完整闭环：学生在某个阶段上传一份新文档，生成一条submission记录。教师在看到学生提交的文档后填写指导意见并记录指导内容时，后端统一将这两部分数据关联存储。如果指导老师超时未处理，系统还可以提醒督促，但那已经是偏任务调度与通知服务方向的高级设计了。

成绩评定页面要能按课题维度展示参加该课题的全部学生，每条学生记录下一键评分，并汇总不同的分数区间。各学校通常设定开题占20%、中期占20%、评阅占30%、答辩占30%等配比，后端把这些权重做成可配置字典，管理员在参数管理里能自己调整。

最终成绩统计展示应该做两张报表：一张是按教师维度的成绩汇总，显示教师辅导的学生数量、平均分、优秀率；另一张是按专业年级维度的成绩分布表，统计优秀、良好、中等、及格、不及格的人数与占比，用饼状图或柱状图展示。在管理页里，统计报表采用图表库实现，比如ECharts，它能在不增加后端报表复杂度的情况下快速做出各种图形化展示，对毕设演示效果而言是很加分的模块。后端只需要额外提供一个统计查询接口，把各种聚合结果查出来。

7. 常见问题、异常排查与避坑手册

7.1 环境类问题速查

7.2 业务逻辑疑难杂症

并发选题是一个经典问题。当两个学生同时点击一个剩余名额只剩一名的课题时，因为前端先查询到的已选人数都相同，然后各自提交申请，后端默认没有锁，导致超员。解决思路是在数据库层面给这条课题记录对应的行表添加排他锁，使用SELECT ... FOR UPDATE先把这条记录锁住，再执行业务校验，使另一个事务必须等待第一个事务完成后才能在更新后的结果里读到新的名额数据。

循环引用导致的JSON序列化失败，是MyBatis关联数据对象的一个典型问题。学生实体内包含List课题集合，课题实体里又包含嵌套的Teacher对象，Teacher对象里还有List，接口返回JSON时，Jackson序列化会陷入递归无法退出，最后抛StackOverflowError。处理方式是在关系的两端添加@JsonIgnoreProperties，将反向引用的属性排除掉，保留正向引用的序列化能力。

再提醒一个重要事项，别在循环体内去逐条查询单条记录。在在成绩列表展示中，只查一个学生的成绩列表很简单，但一旦你在循环里看到教师或者课题信息，就会不断发SQL出去，接口性能在数据量稍微变大后下降得非常明显。这种做法在开发中属于经典的N+1查询问题。我的建议做法是通过一个关联查询把数据一次Join全查出来，或者在内存中构建一个Map，也进一步减少查询次数。

比如一个有30个学生的论文列表，需要显示每个学生的姓名选题，你可以先查询论文列表拿到学生Id集合，再用IN查询一次性把学生名字取回来组装成Map。代码见下：

java复制List<Integer> studentIds = submissions.stream()
    .map(Submission::getStudentId)
    .distinct()
    .collect(Collectors.toList());
Map<Integer, String> studentNameMap = studentService.listByIds(studentIds).stream()
    .collect(Collectors.toMap(Student::getId, Student::getName));

这样数据库的查询次数由原来最多31次下降成固定2次，页面响应速度在数据量较大时差异极其明显。

7.3 应对答辩的代码讲解建议

做这个项目的同学往往把精力放在敲代码上，忽视答辩准备。其实答辩的核心不是说完功能，而是讲明白几个关键设计：系统的角色有哪些，核心业务主流程是怎么走通的，数据库关键表是怎么拆分的，以及“你遇到的最大技术难点是什么”。

论文上传和指导记录关系这个模块是一块非常生动的讲解素材。可以先讲文件存储策略，为什么使用路径存储而不是把文件二进制写入数据库——前者磁盘占用可控、易于备份、可以通过Nginx这类静态服务器加速访问；再讲文件版本管理逻辑。上传的新文件不会覆盖旧文件，提交记录表由唯一的版本号标记，并在前端展示编辑入口。讲了这一段，哪怕实际项目代码只有三五十行，也足以体现出数据建模的设计思想。

如果老师追问角色权限模块，而你的系统用的是自定义拦截器，也可以解释清楚了在庞大系统中用Spring Security做更细粒度权限控制依然是一种扩展方向，并正在项目中预留了接口。这既没有贬低自己当前采用的可运行方案，也展示出了举一反三的能力。

8. 部署上线与实操经验补充

8.1 本机快速运行完整源码：最稳的方式

假设你刚下载了一份完整源码压缩包，先别急着双击运行，按顺序来：

第一，检查并安装JDK 1.8和Maven 3.6+。在命令行执行java -version和mvn -v确认环境变量配置正确，命令行直接显示版本号代表配置成功。

第二，安装MySQL，用Navicat或命令行工具新建一个数据库，字符集选utf8mb4，排序规则选utf8mb4_unicode_ci。将项目SQL脚本导入生成对应的表和初始数据。

第三，使用IDEA打开后端目录，等待Maven自动下载依赖结束。修改application.yml里的数据库地址、账号密码以及服务启动端口。建议先把数据库连接配置信息在命令行验证一下，避免最终启动浪费时间。

第四，在本地后端工程目录下执行mvn spring-boot:run启动，观察控制台没有异常。浏览器直接访问后端地址加登录接口，确认能收到JSON返回方式是否正确。

第五，进入前端目录安装依赖并把开发环境的接口地址指向后端localhost。执行npm run serve工程就可以启动热更新前端页面，浏览器访问9528或5173端口，打开登录页后使用测试账号登录。

8.2 服务器部署与备份建议

毕设服务器部署不使用外部Tomcat，旧式部署方式是把工程打成WAR包塞进tomcat/webapps目录，还有War包需要和内嵌Tomcat版本一致性调来调去的坑。SpringBoot官方给的标准部署方式是打成可执行jar包：

plaintext复制mvn clean package -Dmaven.test.skip=true

构建完成后，在target目录里会有一个xxx.jar文件。服务器上只需要安装对应版本的JDK，把jar包传上去，然后用：

plaintext复制java -jar xxx.jar --spring.profiles.active=prod

就能运行起来。生产配置文件的数据库地址要改成云数据库或服务器本机MySQL账号密码，然后把前端dist里的文件拷贝到static目录下重新打包。

数据库备份最好写一个简单定时脚本，每天凌晨用mysqldump做一次完整备份并保存最近7天的备份文件。毕设答辩时数据丢了，题目做到最后变成重新演示，是历届最惨的翻车现场。脚本命令大致如下：

bash复制mysqldump -uroot -p你的密码 graduation_system > /backup/graduation_$(date +%Y%m%d).sql

将这个脚本配置到crontab里定时执行，每天自动备份。养成勤备份的习惯，这个系统的数据真的是你将近半年的全部心血成果。

不过个人开发的项目放在云端的云数据库上如果安全策略不够完善，风险并不小，把访问白名单精确到自己的服务器IP后再放开。这条习惯无论对什么项目都适用。

9. 给不同读者的直接建议

如果你正在准备做毕业设计，我的核心建议是不要只闭门造车。围绕SpringBoot+Vue这类项目启动前，先把官方教程的快速开始章节完整跑通一遍，再动工。SpringBoot项目用Spring Initializr一键生成初始项目，再让Vue项目用Vite或者Vue CLI快速搭建，这两个脚手架可以省掉很多手工创建配置文件的低级问题。

如果你已经在做开发进行到一半，建议多花时间在“角色-操作-状态”的业务链条上多确认，减少接口推倒重写的次数。也可以先从页面原型角度出发，把教师端、学生端的主流程页面静态画完交给同学体验一下，再切后端逻辑，写代码效率反而更高。

如果你的系统已经能运行，接下来要投入心思做一轮完整测试。分别创建不同角色账号，按真实业务操作顺序走一遍流程；再做一些边界测试，比如超员选题、重复提交论文、越权访问接口、超大文件上传、单用户多终端登录。真实业务过程留下的BUG只有细致测试才能暴露出来，而不是拿着已有的演示数据简单击几次按钮就能验证完毕的。在期末收尾时写操作说明书，把自己在部署过程中填过的配置项留一份带注释的说明文档分享给导师或同届同学，也是很好的知识传递方法。