SpringBoot2+Vue3+MyBatis-Plus构建考试报名系统全栈实战

1. 项目选型背后的真实考量

1.1 为什么是SpringBoot2而不是SpringBoot3

做考试报名系统这类Web项目，很多同学直接就去选最新版本技术栈，这点我其实不太赞同。当前这套项目用的是SpringBoot2，不是这两年主推的SpringBoot3，很多第一次接触的人会问：2025年了还用2.x，是不是落后了？

真实情况是，SpringBoot2.7.x是2代最后一个维护版本，也是整个Spring生态里兼容性最"广"的版本。它支持JDK8到JDK17，而SpringBoot3强制要求JDK17起步，同时把javax命名空间整体迁移到了jakarta。说白了，很多老教程、老博客、以及高校机房预装的JDK8环境，在SpringBoot3下面第一关就过不了。对于考试报名这类以稳定交付为目标的系统，技术栈激进带来的收益远远小于兼容性风险。

SpringBoot2.7.x配合JDK8，部署在哪都跑得起来，这一点在课程设计、毕业设计里尤其关键。你想想，答辩那天指导老师在那台老电脑上让你演示，如果因为JDK版本不一致导致项目起不来，那真是社死现场。所以版本选择不是越新越好，而是越稳越好。

1.2 Vue3与Vue2的体验差异

前端这块选Vue3，主要图的就是组合式API的开发体验和Vite的构建速度。Vue3刚出来那会儿，社区很多人还在犹豫要不要从Vue2迁移，但到今年再看，Vue2已经进入维护末期，新项目直接用Vue3是唯一理性的选择。

相比Vue2的选项式API，Vue3的setup语法糖让逻辑聚合变得更加自然。比如考试报名的表单校验、场地数据加载、提交状态的维护，这些业务逻辑在选项式API里要分散写在data、methods、watch、computed里，而组合式API可以把一套业务的数据和逻辑完整地放在一起，用起来体感好太多。

Vite方面就不多吹了，用过的都知道，冷启动基本秒开，热更新也不会像webpack那样越改越卡。

1.3 MyBatis-Plus为何优于Spring Data JPA

持久层选MyBatis-Plus而不是Spring Data JPA，这个问题我在好几个项目里都权衡过。简单来说，MyBatis-Plus给了你完整的SQL可控性，同时保留了单表CRUD的基础能力。考试报名系统里有大量多表关联、条件动态查询、分页统计的SQL，用JPA那种以实体关系映射为中心的思路来做，反而不如MyBatis-Plus的XML映射和QueryWrapper来得直接。

Spring Data JPA的学习曲线也不低。你需要在脑子里维护实体状态、懒加载、一级二级缓存、DDD聚合那一整套概念，这些对于中小型管理系统来说太重了。而MyBatis-Plus最人畜无害的地方在于它的BaseMapper已经内置了insert、deleteById、selectById、updateById，90%的单表操作不用写SQL，而剩下那10%复杂查询恰好是MyBatis的强项。这就是我选它的核心理由：在开发效率和SQL干预能力之间取了一个很舒服的平衡点。

再加上MyBatis-Plus的分页插件、自动填充、乐观锁插件，这套组合下来写数据层代码能省不少力气。后面我会逐一展开讲。

2. 核心功能模块拆解：考试报名流程里的那些坑

2.1 用户与权限模型

考试报名系统里最核心的身份关系其实只有三种：管理员、考务老师、考生。

管理员负责系统基础配置，包括学期开设、考试项目维护、系统参数管理；考务老师负责考试场次的安排和成绩的录入；考生则是报名流程的主体，登录后查看可报科目、选场次、缴费、查看成绩。

权限模型我用的是经典的RBAC设计，也就是用户-角色-权限三层结构。不论是Spring Security还是Shiro，本质上都是在这个模型上做路由拦截和接口鉴权。开发的时候要注意，别把权限写死在用户表里，否则后面每加一个角色都要改表结构，维护成本极高。

表结构上拆成sys_user、sys_role、sys_user_role三张基础表，再通过一个权限标识（比如exam:registration:add）去控制接口的访问。登录成功后将用户的角色和权限列表放进一个Map里，用拦截器做鉴权，够用且清晰。

2.2 报名并发与考试场次管理

考试报名最经典的业务问题就是抢场次。一个热门考试放出来两百个名额，看上去简单，但一旦并发上来了，超卖问题就会暴露。

我这里采用了两个策略组合：第一，在报名表上建立“考生ID+场次ID”的唯一索引，从数据库层面保证一个考生同一场次不能重复报名；第二，在报名扣减名额时使用乐观锁更新，也就是在exam_session表上增加一个version字段，每次扣减名额的SQL都带上WHERE version = #{oldVersion}，更新成功才提交事务。

这种方式虽然比悲观锁（SELECT FOR UPDATE）在极端高并发下稍微弱一点，但胜在性能好、死锁概率低，对高校这种量级的并发来说绰绰有余。

2.3 成绩管理与状态流转

报名之后还有一条状态要管理好：待报名、已报名、已缴费、已考试、已通过/未通过。这是个典型的有限状态机模型。

状态字段我建议用整数类型存在报名表里，前端根据数值去映射对应的文案与按钮。状态流转的接口要做成"目标状态校验+更新"，不能在Service层用updateById直接改status字段，否则一旦页面按钮控制不好，用户就可能从"已报名"直接跳到"已通过"，整个业务就乱了。

成绩这块一般由考务老师导入Excel或逐条录入，录入完成后触发状态变更。管理员端可以查看按场次、按考试类型、按院系汇总的考试成绩统计报表，这里就是典型的多表联查+分组统计场景，放到MyBatis-Plus里写一个XML的select就好，后端返回一个聚合视图对象，前端用表格展示即可。

3. 数据库设计与MySQL8.0环境搭建实录

3.1 核心表结构设计

数据库设计是考试报名系统的地基，表结构设计得好不好，直接决定后面写业务代码是顺滑还是痛苦。

核心表我认为至少有这六张：

• exam_subject 考试科目表：存放考试名称、考试类型（四级/六级/计算机等级等）、报名起止时间
• exam_session 考试场次表：每个科目下分多个场次，包含考试时间、考场地点、总名额、已报名名额
• sys_user 用户表：账号、密码（BCrypt加密）、姓名、学号/工号
• sys_role 与sys_user_role 角色表及关联表：前面已经说过，不再赘述
• reg_registration 报名表：考生与场次的关联记录。核心字段有user_id、session_id、status、create_time
• reg_score 成绩表：考生、科目、场次、分数、是否合格、录入时间

字段类型上给两个经验：ID用BIGINT，配合MyBatis-Plus的雪花ID策略，避免使用数据库自增主键在外部分库分表时遇到的麻烦；时间字段统一用DATETIME，别再为了那点"空间节省"用TIMESTAMP，否则2038年问题早晚会找上门。

索引方面，除主键外，要给报名表建(user_id, session_id)的唯一索引，给成绩表建(registration_id)的普通索引，给场次表建(subject_id, exam_date)的组合索引，这些是查询频率最高的路径。

3.2 MySQL8.0的两个核心配置坑

MySQL8.0相比5.7，有两个地方让不少新手当场翻车。

第一个是默认认证插件换成了caching_sha2_password。如果你用Navicat旧版本去连接，会直接报Authentication plugin 'caching_sha2_password' cannot be loaded。解决方式有两种：一是升级Navicat到16以上版本，完全兼容；二是在MySQL里执行一行SQL改回兼容模式：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';。我个人建议优先升级客户端，因为换认证插件总归不是长久之计。

第二个坑是URL参数。驱动连接串里一定要带上serverTimezone=Asia/Shanghai和useSSL=false，比如：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/exam_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true

不配serverTimezone会报时区错误，不配allowPublicKeyRetrieval=true，在非本机连接时经常会碰到Public Key Retrieval is not allowed。这几个参数就是MySQL8.0配连接的本体。

3.3 Docker快速拉起MySQL8.0

本地开发我不建议直接往系统里装MySQL，容易把环境搞乱。用Docker跑一个轻量实例最舒服，一条命令的事：

bash复制docker run -d \
  --name mysql8 \
  -p 3306:3306 \
  -e MYSQL_ROOT_PASSWORD=root123 \
  -e TZ=Asia/Shanghai \
  -v /opt/mysql-data:/var/lib/mysql \
  mysql:8.0

数据目录要挂载出来，这样容器删了数据还在。因为官方镜像默认的时区是UTC，所以环境变量里强制指定TZ=Asia/Shanghai。跑起来后用docker ps确认容器状态，再用Navicat或者命令行mysql -h 127.0.0.1 -uroot -p验证一下能不能登上。

这里提一个实际操作中容易忽略的点：Docker容器里MySQL默认只监听3306端口，如果启动时忘记映射-p 3306:3306，外面是永远连不上的，但容器本身看着是活的，很多人就卡在这。

4. 前后端落地与联调的关键细节

4.1 后端分层与统一响应结构

SpringBoot项目的后端分层我基本固定是controller、service、mapper三层，controller只做事路由和参数校验，service层写业务逻辑，mapper层走MyBatis-Plus的基础能力和自定义SQL。这套结构在考试报名系统这种业务量级下完全够用，强行引入DDD分层反而是过度设计。

全项目的接口响应体我统一包装为Result<T>，结构固定为code、message、data三个字段。这样做的好处是前端可以用统一的拦截器去处理全局loading、错误提示和业务Code判断，不用每个接口都去处理一套怪异的响应结构。

另外用@RestControllerAdvice加一个全局异常处理器，所有已知的业务异常（比如重复报名、名额不足、非法状态流转）都通过自定义的BizException抛出，最终统一返回给前端一个合理的JSON。这不仅让代码更整洁，也避免了很多500错误对用户端的赤裸暴露。

4.2 Vite项目结构与接口封装

前端用Vite脚手架创建Vue3项目，npm create vite@latest exam-web选Vue+JavaScript模板即可。目录结构上，我把src/api按模块切分：user.js、exam.js、registration.js、score.js，每个模块对应后端一个controller。

axios二次封装这步不能省，核心配置是baseURL、请求拦截器加token、响应拦截器统一处理业务码和401跳转。大约长这样：

javascript复制const http = axios.create({
  baseURL: '/api',
  timeout: 10000
})

http.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) config.headers.Authorization = `Bearer ${token}`
  return config
})

http.interceptors.response.use(
  res => {
    if (res.data.code === 200) return res.data
    if (res.data.code === 401) {
      router.push('/login')
    }
    return Promise.reject(new Error(res.data.message))
  },
  err => {
    ElMessage.error(err.response?.data?.message || '网络异常')
    return Promise.reject(err)
  }
)

路由守卫用router.beforeEach，只做一件事：判断本地有没有token，没有就放行到/login，有就去往后端校验用户信息再放行。用户信息拿到后存到Pinia里，后续页面展示姓名、角色，不用反复请求后端。

4.3 拿捏权限控制与动态路由

考试报名系统里有三个角色，如果你把全部菜单都渲染在侧边栏，管理员还好，考生点进去全是无权限的红色报错，体验非常糟糕。更优雅的做法是根据角色动态生成路由和菜单。

思路是：登录时后端返回当前用户的角色标识和权限列表，前端用一个generateRoutes()方法把标准路由表过滤一遍，再去router.addRoute()动态注册，菜单侧的导航也按同源数据渲染。这样考生登录只看到"我的报名"“我的成绩”，考务老师能看到"场次管理"“成绩录入”，管理员看到"用户管理"“考试科目管理"“数据报表”。

另外，菜单的图标和路由的meta字段可以提前配好，渲染时直接用，动态菜单就顺带解决了。

5. 典型报错与排查窍门实录

5.1 SpringBoot2启动阶段的常见问题

第一个高频报错是启动时提示Failed to configure a DataSource。原因是pom里引了spring-boot-starter-data-jpa或者mybatis-spring-boot-starter，但application.yml里没有给出数据源的url、username、password。这个报错还有一个变种，就是多模块工程里配置文件没被扫到。检查spring.profiles.active是否指向正确环境，以及target目录下有没有把yml文件编译进去。

第二个是端口被占用，Port 8080 was already in use。Mac和Linux下用lsof -i:8080查PID然后kill掉，Windows下用netstat -ano | findstr 8080。如果不想每次手动关，可以直接在配置里换一个不太常用的端口，比如8090。

5.2 MySQL8.0驱动类的坑

SpringBoot2的数据库驱动要特别注意引入的包。MySQL8.0对应com.mysql.cj.jdbc.Driver，而在MySQL5.x时代用的是com.mysql.jdbc.Driver。

如果你pom依赖里的GAV写的是mysql:mysql-connector-java:5.1.49，跑项目时大概率会遇到Unknown database或Communications link failure，这类问题的原因多半就是驱动版本与数据库版本不一致。SpringBoot2.7其实已经帮你在依赖管理中锁定了mysql-connector-j的版本，所以在2.7.x里直接用：

xml复制<dependency>
    <groupId>com.mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
    <scope>runtime</scope>
</dependency>

这个新的独立坐标是Oracle改版后推荐的，兼容MySQL8.0，用起来没问题。

5.3 MyBatis-Plus的高频报错

MyBatis-Plus最常见的问题之一就是分页查不出数据。明明SQL看着正常，但IPage返回的total永远是0——这是因为没有配置分页插件。在SpringBoot2里通过一个@Configuration类注入MybatisPlusInterceptor，并加上PaginationInnerInterceptor才能生效，这个配置很多人会漏。

第二个高频问题：实体的ID主键策略不统一。如果你的数据库主键是自增的，但实体上没标@TableId(type = IdType.AUTO)，默认的策略会去生成雪花ID，最终出现主键冲突或者插入后查不到数据。记住一个口诀：数据库自增就用AUTO，分布式场景用ASSIGN_ID。

第三个是自动填充不生效，比如create_time插入时没有自动填值。需要在字段上标@TableField(fill = FieldFill.INSERT)，同时写一个实现MetaObjectHandler的组件，在insertFill方法里统一给createTime赋值。这套配置写一次就完事，比每次service层手动set要可靠得多。

5.4 Vue3运行与组件的小坑

Vue3项目最典型的雷区就是Node版本过老导致Vite跑不起来。Vite 4以上要求Node 16+，Vite 5需要18+，如果你用的还是14.x的Node，启动时会直接报语法错误。升级Node建议用nvm，nvm install 18然后nvm use 18，几分钟搞定，不需要折腾系统环境。

另一个是Element Plus组件的监听问题，比如el-upload的on-success一直不触发。这个通常不是你代码问题，而是组件库版本与Vue版本不完全匹配。去看package.json，确保element-plus与你Vue3版本兼容，并且局部注册时用app.use(ElementPlus)全局注册。

还有Vue3里使用sortable拖拽不生效，多半是新版本ESM模块引用方式变了，import Sortable from 'sortablejs'之后还要检查构建器能不能正确解析ESM。如果本地跑没问题、打包部署后失效，优先去查Vite的optimizeDeps配置。

6. 配套文档与项目交付的提示

这套项目标题里带了"含文档"，我多说一句文档这块。很多同学做完系统就只交源码，其实考试报名型的项目文档跟代码一样值钱，工作后更是这样。

文档至少要包含：需求分析（含用例图，哪怕就画几个关键的也行）、数据库设计说明书（表结构说明，字段含义必须写清楚）、接口文档（前端联调的时候全靠它）、以及部署手册。部署手册里最核心的是把JDK版本、Node版本、MySQL初始化脚本的位置写清楚，别让验收的人跟着你一边猜一边配环境。

如果文档能在交付时做一版带截图的关键流程演示，比如"从管理员创建考试科目到考生报名成功的完整截图"，那项目的完整度和可信度会立刻提升一个档次，这也是评估源码项目时被大家普遍看重的一点。我在看别人项目时，第一步就先把数据库脚本建起来，能一把跑通的项目，其余部分基本也不会差。

7. 真实体会与扩展方向

做这类系统这些年，我最大的感触是考试报名看似简单，真正落地时要处理的东西却不少。业务逻辑上的并发下单问题、状态机流转的严谨性、前端权限菜单的灵活性、MySQL8.0环境适配的细节，任何一个环节处理不好，整个系统都会卡在你意想不到的地方。

按我的经验，把这个当成第一个全栈项目来练手是非常合适的。它不像电商系统那样有复杂的商品推荐和支付分账，也不像后台管理系统那样全是纯增删改查，它的业务既有一定挑战度，又控制在一个人能彻底驾驭的范围内。

往后续做，可以考虑做这几个扩展方向：第一个是把考试场次模块改造为通用排课模块，加一个教室资源和监考老师的管理；第二个是增加消息通知，比如报名成功、考试时间变更，通过邮件或站内信的方式推送；第三个是接入一个简单的图表大屏，把各院系报名人数、科目热度、合格率之类的数据做成可视化报表，展示效果会非常加分。

如果你拿到手的是带文档的完整源码，最建议的做法不是直接拿来找工作用，而是自己把它完整跑起来之后，亲手改写几个模块。比如把某个查询改为多条件组合筛选，把某个前端页面从表格展示改成含搜索加分页的完整列表，这些改动做完，项目才算真正变成你的东西。