每年一到毕业季教研组的微信群里就全是“老师这个课题还能选吗”“老师我报错了能不能改”这类消息Excel表格传来传去最后统计的人对着几百行数据崩溃。我也是在第三年接手选题统计的时候决定直接把“毕业设计选题管理系统”做成一套完整项目。这个项目基于JavaSpringBootSSM技术栈把课题申报、学生志愿填报、教师审核、管理员兜底分配、公告通知全流程串起来既能当作教研管理工具用也特别适合作为Java方向的毕业设计题目——因为它覆盖了权限控制、事务处理、并发防超选这些经典面试考点亮点拿得出手答辩也有的讲。这篇文章我会从需求边界、技术选型、核心模块实现、并发与权限难点、踩坑排错、打包交付六个角度把整个系统的设计思路和实战细节完整拆出来。不管你是打算拿这类题目做毕设还是需要在毕设项目里凑一套高质量业务闭环都能直接参考。1. 选题系统到底在解决什么问题需求边界与角色梳理很多人在写需求分析时容易犯一个毛病就是把系统当成普通“管理系统”来写功能一股脑往上堆真正核心的业务规则反而没想清楚。我建议先从“没有系统时到底发生了什么”开始推演。1.1 传统选题流程的痛点在哪里我所在的系里过去学生选题用的是“Excel总表线下签字”的模式。老师把自己能带的方向发出来学生自己去认领确认后手动更新表格。听起来简单实际一乱就乱在三点信息不同步学生看到课题还在表里去找老师时已经被其他同学占掉了回头还得在群里反复问。志愿冲突很多方向是热门方向几个学生同时想要但表格里根本看不出优先级和申请顺序。变更无记录学生想换题、老师想踢人、管理员想补位全靠口头沟通最后统计出问题完全无法追责。更麻烦的是中期还要处理学生选题方向与教师研究方向的匹配度如果没有系统按规则过滤光靠人工核对几十条记录就能耗掉一整天。1.2 三类核心角色和用例边界一个完整的选题系统不需要做得很花哨核心是三类角色、三条主线角色核心权限关键用例学生查看课题、提交志愿、确认结果浏览课题池、填报1~3个志愿、查看审核状态、确认最终选题教师申报课题、审核学生、录入方向要求申报/修改课题、查看申请列表、通过或拒绝学生申请、补充课题说明管理员系统配置、课题审核、兜底分配、数据统计审核教师课题、设置选题时间窗口、手动匹配学生、发布公告、导出统计表这里有个容易被忽略的角色是“教研室负责人”在很多系统里被合并进了管理员。如果题目要求里有“院系管理”这类字眼建议单独抽出一个角色管理员管系统负责人管本院业务数据否则答辩时会被问到“多个院系共用时怎么隔离数据”。1.3 业务规则才是系统的灵魂我在设计表结构前先把业务规则一条条写死这也是后面并发控制和权限判断的依据一个教师最多可申报5个课题超出后前端隐藏申报按钮。一个课题同一时间最多只能被1名学生最终选定申请阶段允许最多3人同时参与排队。一个学生最多可填报3个志愿按优先级排序第一志愿优先参与竞争。选题开放时间内允许学生撤销重选关闭后只能由管理员强制调整。教师通过第1志愿学生后系统自动把该学生其余志愿作废课题状态变为“已选定”。超时未确认的学生管理员可手动释放名额。把这些规则写进需求文档比画一堆用例图有用得多。因为后面你会碰到“学生同时报了课题A和课题B教师A先通过了要不要把课题B的申请自动取消”这样具体的业务问题规则不确定代码就没法写。2. 技术选型SpringBoot和SSM到底怎么组合才不算“重复造轮子”技术选型最怕的就是被评委问一句话“你用了SpringBoot为什么还叫SSM这两个不是同一个东西吗”这个问题我在模拟答辩时被问过如果在场子上一句话答不出来项目印象分会掉很多。2.1 SpringBoot与SSM的关系骨架与零件SSM是SpringSpringMVCMyBatis三个框架的组合SpringBoot则是一个“自动配置容器”它内部默认整合了SpringMVC同时也提供了MyBatis的起步依赖mybatis-spring-boot-starter。所以你完全可以这样说本项目的核心框架是SSM即Spring管理业务对象、SpringMVC负责请求路由、MyBatis负责ORM持久化SpringBoot作为项目的基础骨架负责自动配置、内嵌Tomcat、简化部署让原本繁琐的XML配置以自动化和JavaConfig的方式完成。这样一来技术栈的历史脉络和现代工程化思路都讲清楚了。如果非要说选了SpringBoot而不是纯SSM的理由我一般用“从手动组装到自动化装配”来类比就像以前自己动手装台式机现在买整机——性能一样但省心太多。2.2 项目分层与目录结构的落地这个系统的典型包结构如下src/main/java ├── com.example.graduation │ ├── controller/ # 控制层 │ │ ├── StudentController.java │ │ ├── TeacherController.java │ │ ├── AdminController.java │ │ └── CommonController.java │ ├── service/ # 业务层接口Impl │ ├── mapper/ # MyBatis Mapper接口 │ ├── entity/ # 数据库实体 │ ├── common/ # 统一返回体、分页对象 │ ├── config/ # 拦截器、CORS、定时任务配置 │ └── utils/ # JWT、MD5、Excel导出工具如果你用的是前后端分离方案前端独立放在 /front 下如果用了Thymeleaf服务端模板就不需要额外起前端服务。我建议答辩演示用分离方案因为话题更多、界面美观度好控制而且能讲跨域问题如果怕麻烦Thymeleaf更稳。2.3 数据库设计表不宜多但要能讲出设计依据我的核心表只设计了6张不用刻意堆表数量关键是每张表都能回答“为什么这么设计”。sys_user用户主表含角色字段student/teacher/admin用户名密码、学号/工号、所属院系。subject_info课题表含课题名称、研究方向、选题要求、人数上限、所属教师ID、状态待审核/开放/已满/已关闭。selection_record选题申请记录表含学生ID、课题ID、志愿序号1/2/3、状态待教师审核/通过/拒绝/学生放弃/已失效。notice_info公告表管理员或教师发布的选题通知。course_type / teacher_direction可选做用于进一步描述课题分类和教师方向。选择 record 表做核心表时有一个很关键的字段设计student_idsubject_idstatus联合逻辑必须对最强的业务约束加唯一索引。比如要保证一个课题在排队阶段不能被同一个学生重复申请就在表上建唯一索引uk_student_subject(student_id, subject_id)。数据库的设计好坏直接决定后面选题防超选的实现难度下面运维层要讲的事务和锁都建立在表设计之上。3. 核心模块开发实战从登录鉴权到选题流程闭环整个系统业务流程可以分成“登录—课题池—志愿申请—教师审核—结果确认”五个环节。我按实际开发顺序来讲重点不是代码抄写而是每个环节背后要做的判断逻辑。3.1 登录鉴权不用方法级权限的拦截器就等着被咚咚打脸很多毕设项目写的是“用户登录后跳转不同页面”但没有做真正的身份鉴权这是功能评审中的大坑。我都会用JWT自定义拦截器实现// 登录成功后签发token String token JwtUtil.createToken(user.getId(), user.getRole(), username); // 拦截器核心逻辑 Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { // 放行登录接口 if (request.getRequestURI().contains(/login) || request.getRequestURI().contains(/register)) { return true; } String token request.getHeader(Authorization); if (token null || !JwtUtil.verify(token)) { response.setStatus(401); return false; } // 解析当前用户信息放入ThreadLocal方便后续获取 UserContext.set(JwtUtil.parseToken(token)); return true; }有了这套之后再配合自定义注解RequireRole(teacher)就能在Controller方法上直接做角色限制。学生只能调学生接口教师没法提交选题申请这样的权限控制讲出来才有说服力而不是写个if判断当前角色就完事了。3.2 学生端选题申请事务下的志愿扣减逻辑选题申请是并发最严重的点核心顺序不能乱先校验课题状态、再检查人数、再写入申请记录。这段代码我在毕设里反复优化过最终落地方案是这样的Transactional(rollbackFor Exception.class) public boolean applySelection(ApplyRequest req) { // 1. 校验课题是否存在且处于开放状态 SubjectInfo subject subjectMapper.selectById(req.getSubjectId()); if (subject null || !subject.getStatus().equals(Status.OPEN)) { throw new BizException(课题不存在或未开放); } // 2. 校验学生已有志愿数量 int count selectionMapper.countByStudentAndActive(req.getStudentId()); if (count 3) { throw new BizException(志愿数量已达上限); } // 3. 写入申请记录并防止重复申请 SelectionRecord record buildRecord(req, nextPriority); selectionMapper.insert(record); return true; }这段代码看起来简单实际并发下会有问题后面我会用一整节去讲为什么仅凭Java代码判断“未满”是不够的。这里先记住一点新增记录必须加唯一索引兜底。3.3 教师审核闭环通过后要“顺手”处理其他关联申请教师点“通过”时事务里要做三件事更新申请记录状态为“已通过”。将学生其他未处理的申请全部置为“已失效”。更新课题状态为“已选定”并关闭课题报名入口。逻辑顺序不能反。大部分新手只做了第1步导致同一个学生占着多个课题、同一个课题躺着多个待审申请最终统计一塌糊涂。这三步放在同一个事务里任何一个失败都整体回滚数据才不会有脏状态。管理员端相对简单主要是课题审核列表、用户管理、公告管理、统计导出。统计导出我推荐用EasyExcel一行注解就能搞定表头后台生成本地文件或直接在服务器生成Excel模板返回前端下载比POI写大量代码省事得多。4. 难啃的骨头并发防超选和权限边界没处理好在评委眼里就是“玩具系统”如果你把系统只停留在“能跑”的层面那和课设没有区别。毕业设计想拿高分必须在答辩里主动展示你对复杂问题的思考。并发防超选就是现成的加分点。4.1 到底会发生什么并发问题场景非常明确某热门课题还剩1个名额两个学生同时点击“申请”。如果代码逻辑是“select count → 判断3 → insert”那两次请求可能都查到同一个count值同时通过判断先后插入记录最终名额被超出。如果不处理你只能对评委说“我们手动限制”那就失败了。4.2 三套方案的选择与取舍方案原理优点缺点适用场景数据库唯一索引对关键列建唯一约束插入冲突直接报错代码最简无额外依赖冲突靠异常控制体验不如主动提示必做兜底乐观锁version更新时校验版本号不匹配则更新失败适合并发不高可重试冲突后需要事务重试推荐主方案SELECT FOR UPDATE查询时锁行后续插入被阻塞强一致、直观长事务风险大、性能差少量热点课题可用本科毕设里我建议“唯一索引兜底 乐观锁提示”。具体做法是给subject_info表加version字段// 乐观锁更新 int rows subjectMapper.reduceStockWithVersion(subjectId, version); if (rows 0) { throw new BizException(课题名额已被抢占请刷新后重试); }底层SQL类似UPDATE subject_info SET selected_count selected_count 1, version version 1 WHERE id #{subjectId} AND version #{version} AND selected_count max_count;4.3 权限设计的四层防线我见过很多系统把权限控制写死在Controller里简单但没法扩展到多角色。推荐一套四层防线表结构层sys_role、sys_menu、sys_user_role、sys_role_menu。拦截器层校验登录状态和token有效性。注解层自定义RequireRole做方法级校验。数据层教师查询时强制拼接where teacher_id 当前用户ID防止越权访问他人课题。这样每条链路都能单独回答“为什么”。答辩时把这四点讲出来基本就是一套标准RBAC模型比单纯说“我用Spring Security”要实在得多。4.4 超时未确认的自动释放功能选题系统里经常有这种场景教师通过了学生的第1志愿学生一直不确认名额被白白占用。我用Spring的Scheduled加了定时任务每天凌晨2点执行一次Scheduled(cron 0 0 2 * * ?) Transactional(rollbackFor Exception.class) public void autoReleaseUnconfirmed() { ListSelectionRecord overdueList selectionMapper.listUnconfirmedOverdue(); for (SelectionRecord record : overdueList) { selectionMapper.updateStatus(record.getId(), Status.INVALID); subjectMapper.releaseStock(record.getSubjectId()); } }这种“定时状态机”的组合功能放在系统里业务完整性一下子就上来了而且还顺带复习了Spring Task的知识点。5. 踩坑实录从本地跑通到答辩演示的完整排错链路写这个部分主要是为了给即将交付项目的人提个醒代码能编译只是开始真正折磨人的是环境问题和演示翻车。5.1 跨域与前端联调前后端分离的第一个大坑我用VueSpringBoot做分离时最常遇到的就是“接口通了但浏览器报CORS错误”。排查链路是这样的先确认SpringBoot服务端口和前端代理请求的地址是否一致。再检查浏览器Network标签里的状态码401说明鉴权没过403说明跨域策略拦截。最后确认后端是否配置CORS允许源。最简单的方式是允许前端开发地址跨域访问Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(http://localhost:*) .allowedMethods(*) .allowCredentials(true); } }注意一点如果配置了拦截器需要确保CORS配置在SpringMVC的拦截器排序中优先生效否则所有请求都会在鉴权前被拦截器挡下。5.2 SpringBoot版本升级从1.x跑到2.x的兼容性雷区我这个项目最初是在SpringBoot 1.5.9上开发的后面为了答辩时用新版特性而升级到2.7。踩了一串坑最有代表性的有三个驱动类改名com.mysql.jdbc.Driver变成了com.mysql.cj.jdbc.Driver好在写成com.mysql.cj.jdbc.Driver后新版也能用。连接串时区问题URL里必须显式加serverTimezoneAsia/Shanghai不然时间全报错。配置文件多环境变量spring.profiles改成spring.profiles.active旧写法不生效导致加载不了生产配置。排查思路是先用mvn spring-boot:run把本地跑起来确认没问题后再打包扔到服务器上用java -jar带--spring.profiles.activeprod启动看报错日志逐步定位。不要直接跳进代码里改免得把业务逻辑也改乱了。5.3 演示现场的数据准备与“不翻车”技巧答辩翻车80%不是代码问题是数据问题。我建议在演示前准备一套“演示三态”数据正常态课题池有未选、已选、已满、关闭四种状态的题目。冲突态故意构造一个“学生已报3个志愿”的场景方便讲业务规则。权限态一个非教师账号尝试访问教师接口展示拦截器拦截。现场演示时用浏览器的“隐身窗口”同时登录教师和学生账号切换角色不用反复重新输入账号密码演示节奏会流畅很多。如果条件允许准备一条备用步骤后端接口Mock数据提前录好万一路由或浏览器出问题直接调用静态接口也能把流程顺下来。6. 从源码到交付调试文档、打包部署与答辩讲解的整理思路一套毕设项目交付出去不只是源码本身。标题里提到的“源码LW调试文档讲解”其实才是真正的完整交付物处理得好大大加分处理不好很容易让整个项目显得不靠谱。6.1 多环境配置与打包命令项目里我把配置拆成三份底层公共application.yml 开发环境application-dev.yml 生产环境application-prod.yml。数据库、Redis、文件上传路径都放在环境配置里。打包时用Maven profile切换mvn clean package -DskipTests -Pprod部署时直接在服务器执行nohup java -jar graduation-system.jar --spring.profiles.activeprod app.log 21 这套配置写进调试文档别人照着操作一次就能跑起来不用猜你是不是忘了给他数据库脚本。6.2 调试文档怎么写才真正有用很多人写的调试文档就是“导入SQL运行项目”八个字这等于没写。我比较推荐把调试文档按读者视角分成三块环境准备清单JDK版本、Maven版本、MySQL版本、Node版本、IDE插件每一项用表格列清楚。启动顺序先导库、再改配置、再启动后端、最后启动前端。异常排查对照表端口占用、数据库连接失败、跨域、前端依赖缺失每个问题给一句可能的报错文案和解决方式。这样的调试文档让一个从没接触过项目的新手也能在10分钟之内把系统跑起来。放在答辩展示里也是一种“工程化能力”的展示。6.3 答辩讲解的讲述顺序答辩时间一般不超过8分钟建议按这个顺序讲业务背景与需求痛点1分钟为什么做选题系统解决了什么实际问题。系统架构与技术选型1分钟SpringBootSSM的分工前端和后端如何通信。数据库设计1分钟说清楚6张表和核心约束重点讲唯一索引和状态字段。核心流程演示3分钟从教师端申报课题→学生选题→教师审核→结果确认跑通一条完整流程。技术亮点与应用难点2分钟并发防超选、权限控制、定时任务、跨域处理。讲的过程中每个环节都要有“遇到了什么问题、我是怎么思考的”这样的叙述逻辑。与其背一堆名词不如主动展示“我为了防超选同时用了唯一索引和乐观锁”这种具体处置思路。评委也是人一听就知道你是真的写过程序还是只是下载了别人的源码。我个人在多次迭代这套系统时的体会是真正给自己加分的从来不是哪一行炫技代码而是你有没有把一件小事做完整——比如学生提交志愿后教师端能实时看到待办提醒比如导出Excel时每个字段有没有对齐再比如被并发抢报名时的友好提示。一个选题管理系统看起来简单但凡是需要被人真正使用的系统细节就是魔鬼。希望这篇拆解能帮到你也祝答辩顺利。