选这个题目做毕业设计，算是踩在了一条又稳又宽的赛道。SpringBoot+Vue+MySQL这套组合，在当前的毕设生态里几乎是标准答案级别的存在：后端生态成熟、前端组件丰富、数据库资料遍地都是，只要你把业务逻辑做扎实、把部署流程走通，答辩时能讲清楚每个模块“为什么这么设计”，基本就是稳稳的优。考务报名平台又是一个非常典型的“轻业务重流程”系统，用户端报名、管理端审核、考场安排、成绩发布，整条链路覆盖了常规Web开发里最常考的那几个点：权限认证、状态流转、关联查询、数据统计。这篇博文就把整个项目的思路、表结构设计、核心接口实现、前后端对接、论文撰写和部署全流程拆开讲一遍，给正在做类似题目的同学一个能直接参照的完整样本。
1. 项目概述与整体设计思路
1.1 为什么选考务报名平台这个题目
很多同学选毕设题目的时候，容易陷入两个极端：要么太简单，比如单表增删改查，答辩的时候老师随便一问缓存怎么设计、并发怎么处理就卡住；要么太复杂，比如做电商秒杀系统、做分布式IM，以本科阶段的时间和精力根本撑不起来，最后草草收场。考务报名平台恰好卡在中间——业务逻辑不复杂到失控，但也不是无脑的CRUD，它天然包含了至少三种用户角色（学生、考务管理员、系统管理员），有报名状态流转（待审核、已通过、已驳回、已缴费），有考场编排这种稍微需要一点算法思维的模块，还有报名人数统计这种需要聚合查询的功能。从毕设评分标准来看，这些点覆盖了“需求分析、系统设计、系统实现、系统测试”的全流程，每一环节都有东西可以写、可以讲。
再从就业角度考虑，SpringBoot+Vue前后端分离是目前中小型公司最主流的开发模式，你用这套技术栈做完一个完整项目，等于提前把工作中最常用的技能树点了一遍。我之前带过几个学弟，毕设做的是类似的管理系统，面试的时候直接把项目部署地址和GitHub仓库丢给面试官，聊了半小时的权限设计和数据库索引优化，比背八股文有用得多。
1.2 技术选型的核心考量
先说后端。SpringBoot 2.7.x是我个人推荐的版本，不要用3.x。SpringBoot 3要求JDK 17起步，很多学校的实验室机器装的是JDK 8，而且网上大部分教程、博客、毕业设计参考资料都是基于SpringBoot 2.x写的，遇到问题搜解决方案会顺手得多。如果用2.7.18这个版本，搭配JDK 8，可以说是毕业设计界最稳的组合，没有之一。
持久层框架选择上，MyBatis-Plus要好于原生MyBatis。原因很简单：MP提供了BaseMapper，单表CRUD写都不用写，敲几个方法名就完事，能把大量时间省下来做业务逻辑。更重要的是，MP的LambdaQueryWrapper写条件查询非常直观，比如查询某个考试下所有已通过审核的报名记录，一行代码就能搞定，比手写XML里的动态SQL短太多了。但要注意一点：答辩的时候老师很可能会问“MyBatis和MyBatis-Plus的区别”，你要能答出来MP是在MyBatis之上做的增强，底层还是MyBatis那一套，并不是替换关系。
前端选Vue 2还是Vue 3，这要看你的基础和时间。如果之前没怎么写过Vue，我建议直接学Vue 3，因为Vue 3现在是绝对主流，而且Composition API写起来逻辑聚合度更高，一个报名流程的接口调用、状态处理、页面渲染可以写在一个setup函数里，比Vue 2的Option API的“所有data在一堆、所有methods在另一堆”要好维护得多。配合Element Plus组件库，后台管理界面基本就是拖组件拼页面，开发效率翻倍。如果学校教材用的还是Vue 2，那就用Vue 2 + Element UI，道理一样，关键是别在选型上浪费太多时间。
数据库这块，MySQL 8.0是标配。需要提醒的是，MySQL 8的默认认证插件是caching_sha2_password，而一些旧版可视化工具或者JDBC驱动连接时会报“Authentication plugin”错误。如果遇到这个问题，要么升级驱动，要么在创建用户时指定mysql_native_password认证方式。后面部署章节我会再细说，这里先有个印象即可。
2. 数据库设计：考务系统的地基
2.1 核心表结构与字段设计
数据库设计是整个项目里最不能糊弄的部分，因为后面所有接口、所有页面都是在表结构的基础上长出来的。表设计一旦定了，改起来牵一发动全身。我在这套系统里一共设计了7张核心表：用户表、考试表、报名表、公告表、考场表、成绩表、操作日志表。下面挑重点讲。
用户表（sys_user）的核心字段不用多：id、username、password、real_name、role（学生/管理员/超级管理员）、phone、email、status、create_time。这里有两个容易被忽略的细节。第一，password字段长度至少设为64，因为后续会用BCrypt加密存储密文。第二，role字段不建议用简单字符串存“学生”“管理员”，存字符串会带来两个问题：一是中文字符串占空间大，二是如果有人想扩展角色，字符串维护起来很麻烦。更好的做法是存数字或英文标识，0代表学生、1代表管理员、2代表超级管理员，前端再通过字典映射成中文展示。
考试表（exam）设计上要覆盖一个考试场次的最小信息：id、exam_name、exam_type（笔试/机试/面试）、registration_start_time、registration_end_time、exam_start_time、exam_end_time、total_capacity（总容量）、cur_registered_count（当前已报名人数）、status（未开始报名/报名中/报名结束/考试中/已结束）、description。这里cur_registered_count字段是我特别建议加的，它看起来冗余，但对报名页面来说太关键了——学生查看考试列表时，如果每个考试都要COUNT一次报名表才能拿到已报名人数，考试一多，查询效率就会肉眼可见地变差。这种“用空间换时间”的冗余字段设计，在答辩时也是一个可以主动讲的优化点。
报名表（registration）是整张ER图的核心，字段包括：id、exam_id、user_id、registration_time、status（待审核/已通过/已驳回/已缴费/已取消）、audit_comment、audit_time。需要注意，exam_id和user_id要建联合唯一索引，防止同一用户对同一考试重复报名。这个不建索引的话，理论上用户连续点两次报名按钮就可能插进去两条记录，别问我怎么知道的……另外status字段建议用tinyint存，0待审核、1已通过、2已驳回、3已缴费、4已取消，每个状态之间的流转关系在代码里做严格校验，而不是页面想改哪个状态就改哪个状态。这个“状态机”设计，也是答辩加分项。
2.2 表关系与索引优化
三张核心表的关系很清晰：用户和考试是多对多的关系，报名表就是中间表；一个考试有多个考场，考场表和考试表是一对多关系。画ER图的时候，把用户表、考试表、报名表放在中心位置，公告表、成绩表环绕周围，整个图看起来就非常规整，放进论文里也好看。
索引这块，除了报名表的联合唯一索引，还有几个必须建的：registration_time的普通索引，因为后台管理页面经常按报名时间排序；exam表的status索引，因为首页列表要筛选“报名中”的考试；user表的role索引，因为管理端要按角色过滤用户列表。有个面试里常被追问的点是：为什么不给所有字段都建索引？答案是索引虽然能加速查询，但会拖慢插入和更新速度，同时占用额外磁盘空间，属于典型的“以空间换时间”，合理的做法是只给高频查询字段和需要排序的字段建索引。
2.3 初始化数据与系统账号
在写后端接口之前，先往数据库里塞一批初始数据，这对后续联调和测试极其重要。我是写了一个SQL脚本，里面包含了：一个超级管理员账号（admin/admin123）、两个管理员账号、二十个测试学生账号、五场不同状态的考试数据、若干条公告。另外有个细节：密码不是明文存进SQL的，而是先把BCrypt加密后的密文塞进去。做法是先写一个简单的Java测试类，用Spring Security自带的BCryptPasswordEncoder生成几组密文，再复制到SQL脚本里。这样系统启动后，那些测试账号就能直接登录，不用再走注册流程。
3. 后端实现：SpringBoot核心模块实战
3.1 项目结构与统一响应封装
SpringBoot项目的基础结构我是按功能模块分包，而不是按技术分层分包。所谓按功能分包，就是报名相关的Controller、Service、Mapper放在signup包下，考试相关放在exam包下，用户相关放在user包下。这种组织方式的优势在维护阶段体现得很明显：你想改报名模块的逻辑，只需要翻开signup包，所有相关文件都在里面，不用到controller包翻一遍、service包再翻一遍。
统一响应类是每个接口的“标准信封”。我定义了一个Result类，里面三个字段：code（20000代表成功、50000代表失败，用这种大数值少踩坑，因为HTTP状态码本身是200、404、500这样的三位数，业务状态码用五位数的20000体系可以避免混淆）、message（提示信息）、data（真正的业务数据）。每个Controller的方法都返回Result，前端拿到后先判断code再取data。这个规范固定下来之后，前后端联调的时间会大幅缩短，因为大家都照着同一个格式走，不会出现“这个接口返回的是对象，那个接口返回的是数组”的混乱局面。
线程安全的问题也要从一开始就考虑。SimpleDateFormat是线程不安全的，如果要在并发场景下格式化日期，用LocalDateTime配合DateTimeFormatter去替代。当前登录用户的信息，我从JWT里解析出userId后，用ThreadLocal暂存，在Controller层取出放进一个UserContext对象里，后续Service层要用就直接从UserContext拿。这个写法简洁干净，也不需要额外引入其他依赖。
3.2 认证授权：JWT + Spring Security
登录认证是整个系统最核心的公共模块。我用的是JWT + Spring Security这套方案。为什么不用Session？因为前后端分离架构下，前端和后端通常是两个不同域名或端口，跨域情况下Session的Cookie携带比较麻烦，而JWT把用户身份信息加密放进token里，前端拿到token后存到localStorage，之后每次请求在header里带Authorization字段就行，天然适合前后端分离。
实现流程是这样的：用户提交用户名密码，后端校验通过后，用SecretKey签发一个有效期为24小时的token，里面放了userId、username、role三个关键信息。前端把token存起来，之后每次请求在axios拦截器里统一加上Authorization头。后端写一个JwtAuthenticationFilter拦截所有请求，从header取出token并解析，解析成功就把用户信息放入SecurityContext，失败就抛出未认证异常。
这里面有个细节非常值得注意：JWT天然无法在服务端主动失效，所以如果用户修改密码或者被管理员封号，已经签发的token在到期之前依然有效。这显然是个安全隐患。我的解决方案是用一个简单的Redis缓存黑名单：用户登出时把token的jti（唯一ID）存进Redis，过期时间设为token剩余有效期；每次请求进来先查Redis，如果jti在黑名单里就直接拒绝。这个方案成本低、效果好，在论文里写出来是一个很有技术含量的优化点。
3.3 核心业务接口的实现要点
报名接口是整个系统最关键的接口，也是最容易出并发问题的地方。学生提交报名申请后，后端要做这几件事：校验用户角色必须是学生、校验考试状态必须是“报名中”、校验当前时间必须在报名起止时间范围内、校验考试容量是否已满、校验是否重复报名。如果都用编程式的if判断，并发情况下会有严重的问题：两个学生同时看到剩余名额为1，同时发起报名，双方都通过了容量检查，结果一个考试超员了。
解决方案是用数据库层面的事务和锁。具体做法是在select考试记录时加FOR UPDATE行锁，把容量判断和更新放在同一个事务里，这样同一时间只有一个请求能拿到该考试记录的锁，另一个请求会阻塞等待，拿到锁后重新查询发现名额已满，就抛异常提示“该考试名额已满”。这个方案在毕业论文里能写出很大一段内容，而且完全经得起追问。
审核报名接口是管理端的高频操作，学生提交报名后，管理员在后台看到待审核列表，点击通过或者驳回。这里要注意驳回时一定要填写原因，这个原因会通过报名状态接口返回给学生前端，在学生的“我的报名”页面展示出来，让学生知道被驳回的具体原因，而不是干巴巴地显示一个“已驳回”。审核完成后，可以根据学校实际业务决定是否要通知到学生，如果用邮箱就通过Spring Mail发邮件，如果用短信就接入短信平台，毕设里用邮件就够了，代码量小、效果直观。
成绩录入接口相对简单，但有一个坑要注意：成绩表里的exam_id、user_id这两列上也要建联合唯一索引，防止重复录入成绩。管理员录入成绩后，学生端就能在“我的成绩”模块查到自己各场考试的分数，管理员还可以在后台按考试查看某个场次的成绩汇总，包括平均分、最高分、最低分，这里用MyBatis-Plus的聚合查询加一个@Select注解即可实现。
3.4 单元测试与接口调试
这里说一点很多同学不重视但我强烈建议做的事：给Service层的核心方法写单元测试。Spring Boot对测试的支持非常好，在pom里引入spring-boot-starter-test依赖，写一个标注了@SpringBootTest的测试类，就能自动装配数据库和Service。
我主要测试三个场景：测试报名接口报名成功、测试重复报名被拦截、测试容量已满时抛出异常。mock出两个不同的用户，反复调用报名Service，跑通三个用例。这样做的好处有两个：第一，答辩时老师问“你的系统测试做了吗”，你直接把测试类和测试报告截图贴出来，比口头解释有说服力得多；第二，后面改代码的时候，跑一遍测试就能知道有没有改出问题，相当于给自己上了道保险。
接口调试工具我首选Apifox。它是Postman和Swagger的结合体，在Apifox里定义好接口文档，就能直接用mock数据调试前端页面，前端不用等后端接口写完就能开工，大大缩短联调周期。所有接口定义完之后，还能一键导出OpenAPI规范的JSON文件，这个文件本身也可以放进论文附录里。
4. 前端实现：Vue3 + Element Plus
4.1 前端工程搭建与目录规划
前端用Vue3官方脚手架Vite创建工程，命令很简单，npm create vite@latest exam-frontend -- --template vue，后面再装vue-router、pinia、axios、element-plus这些核心依赖。
创建完工程后，我习惯先把目录结构规划好再动手写代码。src目录下面分api、router、stores、views、components、utils这几个子目录。api目录按业务模块存放接口调用文件，比如exam.js、signup.js、user.js；stores目录放Pinia的store；views目录放页面组件，考务管理端和学生端各自占一个子目录；components目录放公共组件，比如上传组件、分页组件；utils目录放axios封装、token处理、日期格式等工具函数。
一个很容易被忽略但很重要的配置项是前端跨域。如果你在本地开发，前端跑在localhost:5173，后端跑在localhost:8080，端口不同就算跨域，前端axios请求会被浏览器拦截。解决方案是开发环境用Vite的proxy代理，在vite.config.js里配置server.proxy，把所有以/api开头的请求都转发到http://localhost:8080。这样前端的axios请求地址只要写/api就能绕开跨域问题。生产环境因为前后端部署在同一台服务器的不同端口，用Nginx反向代理同样可以解决，这个放到部署章节再展开。
4.2 路由设计与会话管理
考务报名平台的角色天然适合用路由守卫做权限控制。路由表分为三类：公开路由（登录页、首页公告）、学生路由（考试列表、我要报名、我的报名、我的成绩）、管理员路由（用户管理、考试管理、报名审核、成绩录入、公告管理）。在路由配置的meta里加上roles字段，声明哪些角色可以访问这个页面。
然后在router.beforeEach这个全局前置守卫里做三件事：第一，判断当前路由是否需要登录，如果要去的是受保护页面但本地没有token，直接重定向到登录页；第二，从Pinia里拿当前用户信息，如果还没有就调用getInfo接口获取；第三，判断当前用户角色是否在路由meta.roles的白名单里，不在就重定向到403页面。
这个路由守卫写完后，体验上的感觉就是整站自动有了访问控制，学生访问管理端页面会被拦下来，未登录用户访问个人中心会跳到登录页。写论文的时候，这里的“基于角色的访问控制”是一个完全可以展开讲两页纸的内容。
4.3 核心页面与组件实现
考试列表页是学生的“主战场”。页面顶上是一个搜索区，支持按考试名称模糊搜索、按考试类型下拉筛选；下面是一个表格，每行展示考试名称、类型、报名时间、考试时间、总容量/已报名人数、状态。最右侧的操作列根据状态动态渲染：报名中且未报名的显示“我要报名”按钮，已报名的显示“已报名”，已结束的显示“查看成绩”。这个动态按钮的按钮态逻辑写完后，整个页面的交互体验就非常OK。
报名流程的交互我认为用弹窗比跳转新页面更优雅。点击“我要报名”后，弹出确认框，展示考试的基本信息和考生姓名，确认后调报名接口。报名成功后按钮立即变为“已报名”，同时本地已报名人数+1。这种局部刷新比整页reload体验好得多，而且用Element Plus的ElMessage组件弹出“报名成功”的轻提示，交互反馈非常明确。
管理后台的报名审核页是另一个重点页面。点击“通过”或“驳回”后要二次确认，避免误操作。驳回时必须填写原因，原因不会为空，这个校验在前端用Form的rules规则限制，后端Service里也会做非空判断，双重保险。审核通过后，列表当前行的状态列即时更新，无需刷新整个页面。
4.4 状态管理与数据联动
Pinia在考务报名平台里的应用我主要放在两个store里：userStore存当前登录用户信息和登录状态，examStore存当前考试列表的筛选条件和分页参数。userStore里的用户信息在登录成功后写入，之后整个系统任何组件需要拿到当前用户信息，直接调用userStore就行，不用再向后端发起请求。
关于分页，前端表格组件和后端接口的配合要固定一套规范。我采用的是pageNum和pageSize两个参数传给后端，后端返回total和records两个字段。前端拿到这些数据后，把total传给el-pagination组件的total属性，点击分页时触发handlePageChange函数重新请求列表。整套分页逻辑封装好之后，考试列表、用户列表、审核列表、成绩列表四个页面都是复用同一套分页逻辑，改起来很省事。
5. 论文撰写的思路与框架建议
5.1 论文整体框架设计
毕业论文的框架基本是固定的，考务报名平台也不例外，但是内容上完全可以写得更有深度。第一章绪论，要交代清楚你为什么做这个系统，这时候可以提现阶段的考务管理痛点：线下报名效率低、人工统计容易出错、信息传递不及时。第二章相关技术介绍，把SpringBoot、Vue、MyBatis-Plus、MySQL、JWT这些技术栈各写一小节，每小节包括技术简介、为什么选择它、你在这个项目里用到了它的哪些特性。第三章需求分析，这里一定要画用例图，学生用例、考务管理员用例、系统管理员用例各一张，再配合用例描述表，写清楚每个用例的前置条件、基本事件流和异常事件流。第四章系统设计，包括总体架构设计、功能模块设计、数据库设计，数据库设计里要有ER图和每张表的建表语句。第五章系统实现，按用户管理、考试管理、报名管理、成绩管理、公告管理五个模块逐一描述，每个模块包含页面截图、核心代码片段和业务逻辑说明。第六章系统测试，写测试方案、测试用例、测试结果分析。最后一章总结与展望，这部分最忌讳只写“本次设计让我学到了很多东西”，要具体总结你完成了什么、有什么不足、未来还能怎么改进。
5.2 论文中核心技术亮点怎么写
关于并发控制的实现，我推荐论文里写成一个小节：描述清楚问题背景（并发报名可能超员）、解决方案（悲观锁FOR UPDATE）、实现代码片段、测试结果。这一小节写出来大概1500字，技术含量足够撑起一个完整章节。
JWT权限认证也是一个可以重点展开的内容。从Session到Token的演进过程、JWT的结构解析（Header、Payload、Signature）、在这个项目里如何结合的Spring Security实现认证流程，连同代码截图和时序图，又能写一个完整小节。如果后面还做了Redis黑名单优化，把那段优化逻辑也写进去，论文的“技术深度”评分直接上了一个台阶。
5.3 图表清单与排版技巧
论文里的图表是答辩老师快速了解你系统的窗口。我建议必须包含的图表有：系统功能结构图、系统总体架构图、系统ER图、各模块的流程图或时序图、几张核心页面截图、数据库建表语句表格。绘制工具方面，架构图和流程图用ProcessOn，ER图用Navicat直接把表结构导出来，再在ProcessOn里调整排版，页面截图用浏览器无痕模式打开系统，避免地址栏里带着本地路径之类杂七杂八的信息。
排版上有一个很容易踩的坑：代码片段尽量不要截图，直接把文字复制进论文，调成等宽字体，比如Consolas，然后控制好行距和缩进。截图代码会显得非常不专业，而且答辩老师可能会问“这段代码能不能现场复制出来看看”，到时候就露馅了。
6. 环境部署：从本地到云服务器的全流程
6.1 本地开发环境搭建踩坑记录
先把本地环境整整齐。JDK必须用8，版本高了低了对不上会出各种莫名其妙的编译错误；Maven用3.6.3或3.8.x都行，不要用最新的3.9以上版本，有些老项目和Maven新版本存在兼容性问题。安装MySQL时，Windows上用安装包或解压版都可以，解压版的坑是老版本和新版本在初始化时命令不一样，MySQL 8需要手动执行mysqld --initialize-insecure后再把data目录权限改一下。如果装的时候嫌麻烦，直接用安装包版（msi），一路Next，选好端口和root密码就行，省下来的时间干正事。
前端的Node版本建议用16或者18的LTS版本。版本太高，比如Node 20及以上，有些老一点的依赖在安装时会报错。装Node本身没问题，坑经常出在npm install这一步，如果下载速度慢，把npm源换成国内镜像：npm config set registry https://registry.npmmirror.com。这行命令能为你省下大量时间。
6.2 后端打包与云服务器部署
本地开发调试没问题后，就要部署到云服务器上给答辩老师看了。后端打包命令在项目根目录执行：mvn clean package -DskipTests，打包成功后target目录下会生成一个exam-server.jar文件。为了让部署方便，我在application.yml里配置了多环境支持：dev环境连接本地数据库，prod环境连接云服务器上的MySQL，启动时用--spring.profiles.active=prod指定使用生产环境配置。
服务器系统我用的是CentOS 7.9。部署步骤总结起来就三步。第一步，安装JDK8和MySQL8，MySQL的安装用yum源或者下载rpm包都行，装好后把数据库导进来：mysql -u root -p < exam.sql。第二步，把jar包上传到服务器，用nohup java -jar exam-server.jar > exam.log 2>&1 &命令在后台启动，之后通过tail -f exam.log实时查看日志确认启动成功。第三步，安装Nginx，配置一个server块，把/api开头的请求反向代理到本地的8080端口，同时把前端静态文件部署到Nginx的html目录下。这样一来，访问服务器的IP或域名，就能直接打开系统。
6.3 前端打包与Nginx反向代理配置
前端打包同样很简单：npm run build，执行完后dist目录就是打包产物。把dist目录里的所有文件上传到服务器的某个目录，比如/usr/share/nginx/html。然后编辑Nginx配置文件，核心内容大致如下：
server { listen 80; server_name your_server_ip; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { try_files $uri $uri/ /index.html; } }这里有两个关键点。第一，location /api/ 一定要靠前写，这样正则匹配时才会优先命中，把接口请求转发到后端。第二，location / 里的try_files配置至关重要，因为Vue Router如果用的是history模式，点击页面后刷新，如果Nginx没有这个配置，会直接返回404。try_files的作用就是：请求路径找不到对应文件时，统一回到index.html，由前端路由接管后续处理。如果用的是hash模式就没有这个问题，但history模式地址栏干净美观，我建议用history模式加这个配置来解决刷新404问题。
6.4 MySQL 8连接问题与权限脚本
部署阶段最常见的坑，就是MySQL 8的认证插件问题。在前端页面登录时报“Access denied”或者后端日志里报“Public Key Retrieval is not allowed”，十有八九是认证插件不匹配。解决办法是新建用户时显式指定：CREATE USER 'exam_user'@'%' IDENTIFIED WITH mysql_native_password BY '你的密码';，然后再GRANT ALL PRIVILEGES ON exam_db.* TO 'exam_user'@'%';。这样Java连接MySQL时就不会遇到认证问题。另外在JDBC连接串上也有个可选的配置：jdbc:mysql://localhost:3306/exam_db?useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai。allowPublicKeyRetrieval=true这个参数就是用来解决连接时“Public Key Retrieval is not allowed”报错的，在开发环境加上它没毛病，生产环境为了安全可以去掉。
7. 答辩准备与项目管理经验
7.1 演示环境的三大纪律
答辩现场演示是很多同学翻车的重灾区。根据我这些年的经验，至少要守住三条纪律。
第一，演示用的环境和数据必须是预置好的。提前在系统里录好学生账号和管理员账号，准备至少五场不同状态的考试数据，让演示时不管点什么都有数据可供展示，千万不能现场注册用户、现建考试，万一网络慢或者接口报错，整个演示流程就卡住了。
第二，提前测试好网络。如果答辩教室的WiFi不稳定，提前把服务器配置好，用自己手机热点做备用网络。演示电脑上提前打开一个命令行窗口ping一下服务器IP看延迟，确保网络通畅后再开始演示。
第三，把“故事线”演练熟。从学生登录、查看考试列表、报名、管理员审核、学生查看审核结果、查询成绩，这条主流程走一遍只花三分钟，但这三分钟就是答辩的黄金时间。每一页展示时配合一句讲解词，比如“这是学生端，可以看到报名中的考试，点击立即报名后提示报名成功”，逻辑要顺畅，不能点得比说得快。
7.2 答辩提问的高频问题与应对思路
答辩老师有三大必问方向：技术原理、业务设计、个人分工。
技术原理方向，老师问得最多的就是“JWT和Session有什么区别”“为什么用MyBatis-Plus”“MySQL的索引是怎么实现的”。这些问题没有标准答案，但一定要能用自己的话讲清楚，特别是JWT那段，建议把“无状态、服务端不存储用户信息、每次请求携带token、服务端验签”这个流程从头到尾顺一遍。
业务设计方向，老师常问“如果报名人数超过容量怎么办”“怎么防止重复报名”“如果同一个用户同时报名多个考试怎么处理”。这些问题的答案都在你项目里：容量校验靠数据库行锁，重复报名靠联合唯一索引，多考试报名是正常业务场景直接支持。回答的时候要把对应代码调出来讲，说到行锁就把Service里那段事务代码截图放大，让老师看到你是真的做了，不是嘴上说说。
个人分工方向，只要不是团队项目，基本就是确认项目是不是独立完成。回答时大方地说“这个项目从需求分析到编码、测试、部署都是我一个人完成的”，然后顺带提几个项目中令你最印象深刻的难点，以及怎么解决的。注意不要吹嘘得太猛，老师追问细节时能对上才是关键。
7.3 代码版本管理与时间规划
代码一定要用Git做版本管理，这个习惯从第一天写代码就要养成。不需要只会git add、git commit、git push这几个核心命令就够了，关键是每个功能模块完成后提交一次，提交信息写清楚，比如“feat: 实现报名审核接口”“fix: 修复报名容量并发问题”。这样做的好处是，如果某天改崩了代码，可以快速回滚到上一个正常版本，不用后悔莫及。
时间规划上，我给一个保守的排期：第1-2周做需求分析和数据库设计，第3-4周完成后端核心接口，第5-6周完成前端核心页面，第7周前后端联调并修复bug，第8-9周撰写论文初稿，第10-11周查重、修改、定稿，第12周准备答辩PPT和演示环境。这个排期有接近一个月的缓冲时间，前紧后松，不会让自己在最后关头崩溃。
8. 常见问题排查与避坑指南
8.1 后端开发阶段的典型问题
CORS跨域问题高居榜首。后端如果没配CORS，前端开发环境的Vite proxy又没生效，浏览器控制台会直接报错。排查思路很简单：先看Network面板里请求有没有发出去，如果发出去了但响应被拦截，说明是后端CORS没配好；如果请求压根没发出去，那就是proxy配置的问题。后端我用一个WebMvcConfigurer配置类统一处理CORS，允许的源按需配置，生产环境尤其不能配成*，只允许你自己的域名访问。
参数校验问题。前端传来的参数，后端一定要做二次校验，不能只靠前端的required规则。比如报名接口的examId如果传了一个不存在的ID，MyBatis-Plus查询会返回null，后面的逻辑就会空指针。统一用javax.validation注解或者手动判断都没有关系，关键是要有。我用的是@Valid注解配合实体类上的@NotNull、@NotBlank这些注解，Controller方法上声明@Valid就完事，Spring框架自动处理校验失败的情况，拦截器统一返回错误提示，代码整洁且逻辑严密。
日志问题。很多同学遇到bug不会排，就是程序里没打日志。我建议每个Service方法的入口和关键分支都加上log.info或log.debug。比如报名接口，进入方法时打印“开始处理报名请求：userId=xxx, examId=xxx”，容量判断通过后打印“容量校验通过，当前已报名人数=xx”，这样一旦出问题，翻日志能快速定位到哪一步挂了。用Lombok的@Slf4j注解，每个Service类加一行注解就能直接使用log对象，非常方便。
8.2 前端开发阶段的典型问题
数据更新后页面不刷新问题。表单提交成功后，列表数据没有变化，排查思路一般是：接口调用成功后有没有重新请求列表数据？我通常用两种方式解决：一种是提交成功后直接调用列表查询接口刷新，另一种是用Pinia的state变更触发组件响应式更新。推荐第一种，简单直接，代码可读性好。
Vue Router切换页面后组件不更新问题。比如学生从报名页跳到我的报名页，报名状态发生了变化，但页面显示的还是旧数据。这通常是因为页面组件被keep-alive缓存了。解决方案是给需要的组件在路由meta里配置keepAlive: false，或者在组件里用onActivated钩子在每次进入页面时重新拉取数据。用后者更通用，但注意onActivated在首次挂载时也会触发，要避免重复请求。
Element Plus组件的使用问题。表单校验、日期选择器、表格排序这些看似基础的组件，在合在一起用的时候经常出问题。比如日期选择器绑定值默认是字符串，需要在提交时格式化为适配后端的格式；表格自定义列模板用template插槽，数据同步更新可能不生效，原因是没有给table组件加row-key。这些问题都不难解决，但最好在开发阶段就把文档过一遍，不要等到联调时才踩坑。
8.3 部署上线阶段容易掉进去的坑
部署阶段的很多坑，上面已经讲了一部分。这里再补充几个容易被忽略的。
第一，服务器防火墙不放行端口，导致外部访问不了。很多云服务器除了系统防火墙，还有一层安全组。如果你在Nginx里配置了监听80端口，但安全组没放行80端口，外部就访问不了。需要在云控制台的安全组规则里，把80端口、443端口，以及后端应用的8080端口（如果也要直接访问的话）都放行。
第二，进程被意外杀掉。用nohup命令启动jar包后，如果关闭SSH终端，进程可能会被终端挂断信号杀掉。解决方法是配合setsid命令或者用systemd服务方式管理，更推荐后者，因为systemd还能做开机自启和崩溃自动重启。写一个exam.service文件，配置ExecStart指向jar包路径，restart=always，然后systemctl enable exam，这台服务器上的后端应用就非常稳定了。
第三，前端访问后端接口404。生产环境下Nginx把/api开头的请求转发到8080端口，但后端项目的context-path如果配置了前缀，会导致路径对不上，Nginx转发不过去。解决办法是可以统一约定Nginx的转发规则和后端接口路径一致，或者在Nginx里做路径重写：proxy_pass http://localhost:8080/;，在proxy_pass最后加个斜杠可以剥离掉location匹配的/api前缀，具体要看项目怎么设计的，规则要对齐。
9. 项目总结与心得体会
做完这套考务报名平台，我最大的体会是：毕业设计的难点从来不在某个单项技术上，而在于把所有零散的技术点串成一条完整业务链。SpringBoot单独学，无非是写几个接口；Vue单独学，无非是做几个页面；MySQL单独学，无非是建几张表。但当它们组合在一起，去实现一个真实可用的报名系统时，各种五花八门的问题就冒出来了：跨域、状态管理、并发控制、部署路径、刷新404……每一个问题单独看都不算难，但解决它们的过程，恰恰就是真正的工程能力在长出来的过程。
最后再分享一个实用的小技巧：建议把整个项目的开发过程用Markdown写一份开发日志，每天记一点，不用写很多，就写今天完成了什么模块、遇到了什么坑、怎么解决的。到毕业论文的“系统实现”章节和“总结”章节时，这些日志就是现成的素材。你只需要把这些口语文档整理成规范的书面语言，论文的写作压力会减轻非常多。这不是什么高深的方法论，但实测下来，比等到最后突击写论文要靠谱得多。
