镝不咸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的分页插件、自动填充、乐观锁插件，这套组合下来写数据层代码能省不少力气。后面我会逐一展开讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心功能模块拆解：考试报名流程里的那些坑
2.1 用户与权限模型
考试报名系统里最核心的身份关系其实只有三种：管理员、考务老师、考生。
管理员负责系统基础配置，包括学期开设、考试项目维护、系统参数管理；考务老师负责考试场次的安排和成绩的录入；考生则是报名流程的主体，登录后查看可报科目、选场次、缴费、查看成绩。
权限模型我用的是经典的RBAC设计，也就是用户-角色-权限三层结构。不论是Spring Security还是Shiro，本质上都是在这个模型上做路由拦截和接口鉴权。开发的时候要注意，别把权限写死在用户表里，否则后面每加一个角色都要改表结构，维护成本极高。
表结构上拆成sys_user、sys_role、sys_user_role三张基础表，再通过一个权限标识（比如exam:registration:add）去控制接口的访问。登录成功后将用户的角色和权限列表放进一个Map里，用拦截器做鉴权，够用