每年到三四月份，高校里的毕业设计选题季就会准时上演一场"大战"：学生盯着系统抢名额、老师对着Excel表格核对重复选题、教学秘书一遍遍催交名单。我经手过好几个基于Java+SpringBoot+SSM的毕业设计选题管理系统项目，说句实在话，这类系统在技术上并不算多高深，但它把一套完整的业务流转、角色权限、状态管理、并发控制都包含了，恰好是毕业设计里“麻雀虽小五脏俱全”的经典选题。本文就把我实际动手开发的完整过程、设计思路、踩过的坑和写论文答辩的经验一次性整理出来，给正在做同款题目或者在找毕设方向的同学一个能直接参考的实操记录。
整套系统的技术底座就是标题里写的Java+SpringBoot+SSM，业务场景则是"毕业设计选题管理"这个具体又刚需的领域。它能做的事情很实在：管理员维护基础数据和整体流程，老师发布设计题目、限制人数、审核学生申请，学生在手机和电脑上浏览题库、提交选题申请、查看审核状态。相比线下排队、Excel统计的传统模式，这套系统把整个选题过程线上化、流程化和可追溯化，省掉大量人工核对工作。适合谁来参考呢？一个是正在做这个毕设题目的计算机相关专业学生，另一个是想把开发流程系统化、从零跑通SSM+SpringBoot完整项目的初学者。下面我按实际动手顺序展开讲。
1. 需求拆解与方案选型：为什么最终选了SpringBoot+SSM
1.1 先把业务场景捋清楚
拿到这个题目，第一件事不是写代码，而是把"选题管理"这四个字背后的业务流程拆明白。我见过不少同学上来就建表、写接口，结果做到一半发现业务逻辑对不上，只能推翻重来。毕业设计选题系统的核心角色有三个：管理员、教师、学生，角色的诉求完全不同。
管理员要负责的是系统维度的管理：维护教师和学生的基础信息，审核教师提交的题目，处理选题冲突，查看选题统计，发布系统公告。教师要做的事很聚焦：发布自己指导的毕业设计题目，设置每个题目的可选人数上限，审核学生提交的选题申请，也可以主动驳回或者改选。学生做的事情最日常：查看所有可选的题目列表，搜索或者按专业筛选题目，提交选题申请，查看审核结果，在老师未审核前可以撤销改选。
这套流程的关键点在于——它不是一条直线，而是一个带状态流转的闭环。从"教师发布题目"到"管理员审核通过"再到"学生申请选题"再到"教师确认"，每个环节都可能回退。如果一开始没把状态设计清楚，后期写业务代码的时候会非常痛苦。
1.2 技术选型背后的真实逻辑
现在说说为什么是SpringBoot+SSM。很多同学会有疑惑：SSM已经是Spring+SpringMVC+MyBatis，为什么还要加SpringBoot？这不是重复吗？
这里要说破一层窗户纸：所谓SSM，指的是Spring、SpringMVC、MyBatis这三种框架的组合使用方式。而SpringBoot并不是替代Spring，它是把Spring家族的使用方式从繁琐的XML配置简化成"约定大于配置"。换句话说，用了SpringBoot之后，底层干活儿的依然是Spring容器、SpringMVC的请求分发、MyBatis的ORM映射，但你不必再手工写一堆applicationContext.xml、spring-mvc.xml、mybatis-config.xml了。
我没有选择最原始的SSM手工整合方案，很大一部分原因是——调试成本。在纯SSM环境下，一个mapper.xml路径扫不到、一个web.xml过滤器顺序不对，都能折腾你好几个小时。SpringBoot的自动装配把这些装配过程包起来，你在application.yml里配个数据源、写个MyBatis的mapper扫描路径，项目就能跑起来。这对毕业设计这个场景来说，性价比是最高的：既保留了SSM这套经典技术栈的学习价值，又不会让环境配置把精力耗光。当然，做毕业设计答辩的时候，老师一定会问"SSM和SpringBoot什么关系"，这个点我在后面论文章节再细说。
1.3 架构分层和项目结构规划
项目结构上，我采用经典的四层结构，这也是SSM类项目最标准的组织方式：
- Controller层：接收请求、参数校验、返回结果
- Service层：业务逻辑处理、事务管理
- Mapper（DAO）层：与数据库交互
- Entity（entity/domain）层：数据库表对应的实体类
同时配合一个common包放统一返回结果、异常处理、工具类，一个config包放拦截器、WebMvc配置。我在实际项目里习惯用Result这类统一封装对象作为接口返回结构，里面包含code、message、data三个字段，状态码用200表示成功，其他表示各种错误。这样做的好处是前端拿到响应后不需要到处猜字段，统一处理异常和提示信息就行。
说一下前后端的问题。用纯JSP做视图层可以跑通，但我个人更推荐前后端分离的方式——SpringBoot提供纯JSON接口，前端用Vue或者Layui+Bootstrap做页面。当时我给其中一个项目搭的是Vue3+Vite+Element Plus的前端，SpringBoot后端只负责输出JSON。这样做的代价是多写一层跨域配置和接口联调的工作，但系统看起来专业不少，答辩时的演示效果也更好。老老实实用JSP+Thymeleaf也能完成，关键是根据自己的前端功底来选。
2. 数据库设计：一个选题系统到底需要几张表
2.1 核心表结构与字段取舍
数据库设计是这类系统里最重要的一环。我总结的一句话是：业务上的一件"事"，对应数据库里的一条"记录"；业务上的一个"状态"，对应数据库里的一个"状态字段"。围绕着选题这个核心业务事件，整个系统可以拆成这几张核心表。
用户相关：sys_user表保存登录账号、密码、角色类型（admin/teacher/student）、姓名、邮箱、手机号等基础信息。这里需要单独说明一下，我不太建议把学生和教师的所有字段都塞进sys_user里，因为学生有学号、班级、专业，教师有工号、职称、所属院系，属性差异比较大。所以拆成student表和teacher表做扩展，sys_user存登录公共信息。实际联表查询时通过user_id关联。
题目相关：topic表，也叫选题表，字段包括题目名称、题目描述、题目要求、所属专业、题目类型（工程设计类/理论研究类/应用研究类）、教师id（发布人）、可选人数上限、已选人数、题目状态（待审核/已通过/已下架/已关闭）。这个表是整个系统业务体量最大的表，因为它是学生浏览和检索的主要目标。
选题记录相关：selection_record表，记录每一次选题申请。字段包括学生id、题目id、申请时间、审核状态（待审核/通过/驳回/已撤销）、教师审核意见、审核时间。这张表是整个系统里状态变化最复杂的表，它记录的是"某学生选了某老师发布的某个题目"这件事的完整生命周期。
系统辅助表：notice公告表（管理员发通知）、department或specialty专业表（用于分类筛选）、sys_log操作日志表（可选，用于记录关键操作）。
2.2 外键的取舍和索引规划
在设计表关系的时候，我发现很多毕设代码里存在两个极端：要么完全不建外键，全靠代码逻辑控制；要么外键泛滥，每个关联字段都建物理外键。我的实际建议是：逻辑外键为主，物理外键尽量少建。也就是说，表和表之间的关联字段（比如topic表里的teacher_id）可以建普通索引来加速查询，但不一定非要在数据库层面建FOREIGN KEY约束。原因很实在，物理外键在删除和更新的时候容易引发连锁限制，而毕业设计系统的数据体量根本不需要数据库层面的强引用约束来保证一致性，反而会给写删除逻辑增加负担。
索引方面，以下几个查询场景必须覆盖到位：selection_record表按student_id查"我的选题记录"、按topic_id查"该题目的申请列表"，topic表按teacher_id查"我发布的题目"、按status查"待审核题目列表"。这些都是高频查询路径，不加索引的话数据量上来之后会明显变慢。主键我用的是自增id，适合这种标准的业务系统，不用纠结雪花ID和UUID的方案。
2.3 状态字段设计是成败关键
这节内容请务必重视。选题系统的核心就是状态机，我强烈建议在表里设计清晰的status字段，并且在一开始就把枚举值规定死。topic表的状态我这样定义：0表示待审核，1表示审核通过可见，2表示已下架/不通过，3表示选题已满自动关闭。selection_record表的状态：0待审核，1已通过，2已驳回，3已撤销。
为什么要单独强调这个？因为实际开发中，最容易出bug的地方就是状态流转没有闭环。我一个实际项目里就遇到过这情况：学生提交选题申请后，教师审核通过，但是topic表里"已选人数"没有同步加1，结果这个题目继续显示可选题，下一个学生还能申请。这就是只改了申请状态、没改题目状态和人数导致的。所以我后来把状态联动明确写在Service层里：学生申请选题 -> 插入申请记录 + 题目已选人数加1；教师驳回 -> 申请状态改驳回 + 题目已选人数减1；学生撤销 -> 申请状态改撤销 + 题目已选人数减1。这些操作都必须放在同一个事务里，保证一致性。
3. 核心功能实现：从登录鉴权到选题并发控制
3.1 登录鉴权与角色拦截器
毕业设计选题系统要不要上Spring Security或Sa-Token这类安全框架？我的建议是：可以上，但没必要强行上。做得比较成熟的项目里通常会直接用Sa-Token，它的API比Spring Security友好得多，适合初学者。但如果你只是想让项目运行稳定、代码可控，手写一个拦截器+Session的登录鉴权方案完全够用。
我实际采用的方式是：登录成功后把用户对象和角色信息放进Session，同时写一个LoginInterceptor拦截器。拦截器里判断Session里有没有用户，没有就重定向到登录页；然后根据请求路径前缀做角色控制，比如/admin/**只允许管理员，/teacher/**只允许教师，/student/**只允许学生。如果角色不匹配直接返回401提示信息。这套方案演示效果够用，答辩时老师会问"Spring Security和拦截器有什么区别"，正好可以展开讲——拦截器只能做粗粒度的URL级别控制，而Spring Security能做方法级、角色表达式等细粒度控制。这个点写进论文里也算一个小亮点。
3.2 学生选题状态机与并发防超选
这是整个系统最核心、也最值得写出亮点的地方。学生选题不是简单的插入一条记录，它涉及三个校验：题目必须是已通过状态；当前已选人数必须小于可选人数上限；这个学生不能重复申请同一个题目（包括历史记录里被驳回的，需要根据业务规则决定是否允许再次申请）。
然后就是并发问题——两个学生同时点击申请选题，都查到当前已选人数是4、上限是5，同时通过校验并插入记录，结果变成一个题目选了6个人。这就是典型的超选问题，解决思路有两个方案。
方案一是在selection_record表里对(student_id, topic_id)建唯一索引，这样同一个学生对同一个题目最多只能有一条申请记录，数据库层面保证不会重复。这个方案实施最简单，但没法解决人数上限的并发问题。
方案二是在合适的时机使用数据库行级锁。我在Service层处理学生选题申请时，使用事务并在查询题目信息时加上SELECT ... FOR UPDATE语句，把这条题目的记录锁住，后面的并发请求要等前面的事务提交后才能继续执行。被锁住后，后续请求查到的已选人数已经更新，校验自然就会失败。这是实际解决并发抢题比较稳妥的办法。为了在答辩中能说明白，我建议在代码里明确写清楚事务隔离和锁机制的使用意图，这属于非常对口的加分项。
3.3 核心代码结构示例
下面给出Service层的核心方法骨架，便于大家直接参考结构。核心逻辑就是：校验题目状态、校验人数、防重复申请，最后插入申请记录并同时更新题目的已选人数。
@Transactional(rollbackFor = Exception.class) public Result applyTopic(Long studentId, Long topicId) { // 1. 查询题目并加锁，防止并发超选 Topic topic = topicMapper.selectByIdForUpdate(topicId); if (topic == null) { return Result.error("题目不存在"); } // 2. 校验题目状态 if (topic.getStatus() != TopicStatus.APPROVED.getCode()) { return Result.error("该题目当前不可选"); } // 3. 校验人数是否已满 if (topic.getSelectedCount() >= topic.getMaxCount()) { return Result.error("该题目选课人数已满"); } // 4. 校验重复申请 SelectionRecord existRecord = selectionRecordMapper.findByStudentAndTopic(studentId, topicId); if (existRecord != null && existRecord.getStatus() != SelectionStatus.REJECTED.getCode()) { return Result.error("您已申请过该题目，请勿重复提交"); } // 5. 插入申请记录 SelectionRecord record = new SelectionRecord(); record.setStudentId(studentId); record.setTopicId(topicId); record.setStatus(SelectionStatus.PENDING.getCode()); selectionRecordMapper.insert(record); // 6. 更新题目已选人数 topicMapper.increaseSelectedCount(topicId); return Result.success("申请提交成功，请等待教师审核"); }对应的SQL注意点：selectByIdForUpdate这个方法的SQL要写成select * from topic where id = #{id} for update，确保它走的是主键索引并且加行锁。increaseSelectedCount不要写成先查后写，直接一条update语句更新人数才是正确做法。再说一遍：这些写操作和上面的insert必须属于同一个事务，否则锁的意义就不存在了。我的经验是给Service方法加上@Transactional注解，并且要当心同一个类中方法自调用导致事务注解失效的问题，这个坑下面会专门讲。
4. 开发中遇到的“知名”坑与排查实录
4.1 框架与配置层面的经典报错
做这类整合型项目，环境问题至少会占掉三分之一的开发时间。我先列几个我实际踩过的、几乎每个同学都会遇到的报错。
第一个是MyBatis的Mapper无法注入，启动就报Field topicMapper in ... required a bean of type ...。排查思路很简单，检查启动类上的@MapperScan扫描路径是否正确，如果使用了@Mapper注解，确认注解写在了每个Mapper接口上。还有一种情况是接口和XML文件的namespace不对应，也是这个报错的原因之一。
第二个是SpringBoot版本和MyBatis Starter版本不兼容。我建议如果用的是SpringBoot 2.x，选择mybatis-spring-boot-starter 2.x；如果用的是SpringBoot 3.x，需要选择mybatis-spring-boot-starter 3.x，因为SpringBoot 3基于Jakarta命名空间，旧版starter在Bean初始化时会直接报错。这个问题在搭建项目的时候就要留意，不要等到跑起来再查。
第三个是时间字段格式化问题。后端返回的LocalDateTime默认序列化出来是一串类似2025-03-15T10:30:00的格式，前端想要的是2025-03-15 10:30:00。解决办法有两种，一是在application.yml里配置jackson的date-format，二是给实体类的日期字段加@JsonFormat注解。我推荐前者，全局统一，省心不少。
第四个是前后端联调时的跨域问题。如果前端跑在8080，后端跑在8081或者9090，浏览器会因为CORS策略把请求拦下来。我在开发环境里直接写一个WebMvcConfigurer配置类，重写addCorsMappings方法允许所有来源跨域。到了生产部署阶段，这个跨域配置就不建议开启了，可以用Nginx反向代理把前后端统一到同一个域名下，这样既解决了跨域，也是答辩时可以拿出来说的项目亮点。
4.2 事务、懒加载与状态不同步
还有几个业务层面的坑比环境问题更隐蔽。先说说事务不生效，这是新手非常容易忽略的经典问题。@Transactional要起作用，必须满足几个条件：方法必须是public的；调用必须是通过Spring代理对象来调用，也就是说不能在一个类的内部通过this调用同类中带有事务注解的方法。我见过有人把applyTopic方法内部的私有方法拆出来加上@Transactional注解，结果事务根本不起作用，因为this调用的不是代理对象。遇到这种情况，要么把方法拆到另一个Service类里，要么自己注入自身代理对象再调用。
第二个坑是MyBatis的一对多、多对一查询时遇到懒加载报错。比如查询一个题目，关联查询教师信息，如果用的是association或collection标签且开启了懒加载，在事务外访问关联对象时会报LazyInitializationException。我的建议简单直接：在resultMap里通过联表查询一次性查出需要展示的关联字段，不需要懒加载就不开；或者fetchType设置为eager。毕设系统里一张表的数据量不大，联表查询性能完全够用，没必要为了省那点SQL搞懒加载，白增加复杂度。
第三个坑就是我前面提到的状态不同步。这类问题的典型表现是：学生申请了选题但题目已选人数没变，教师驳回之后学生仍显示待审核，管理员下架题目后学生依然能发起申请。所有这些问题的根源都在于，状态字段分散在多张表里，业务操作时没有在同一个事务中同步更新这些字段。我的排查方法是：在Service层里列出一次业务操作涉及的所有状态变化，像是"申请选题"这个操作就涉及selection_record的insert、topic表的selected_count加1，缺一不可。写完代码后用事务把这几个写操作包起来，再用单元测试反复验证。
5. 论文（LW）、调试文档与答辩准备的实战经验
5.1 论文结构怎么安排才不空洞
很多同学写完代码之后，对着论文万分纠结，总觉得没什么可写。我给大家一个特别实用的思路：把论文当成"系统设计的完整记录"来写，而不是当成"开发过程的流水账"。评审老师想看的是你面对一个业务问题时的分析和解决过程，重点在于论证"为什么这么设计"。
项目配套的LW一般按照这个章节结构来安排：第一章绪论，写研究背景、国内外研究现状、研究内容与意义；第二章相关技术介绍，用两到三页介绍Java、SpringBoot、SSM、Vue等技术栈，这里要简单说清楚SSM和SpringBoot的边界关系；第三章需求分析，画用例图、功能需求、非功能需求；第四章系统设计，包含总体架构设计、功能模块设计、数据库设计（ER图、数据字典）；第五章系统实现，按功能模块贴关键代码截图、页面截图；第六章系统测试，写测试用例表格和测试结论；最后是总结与展望。
论文写作时有一个很典型的高级技巧：每个功能模块不要只贴代码和截图，要写清楚"输入是什么、输出是什么、关键逻辑是什么"。比如"学生选题功能"这个小节，你可以这样组织：先说明该模块的权限和入口，再画一张业务流程时序说明学生提交申请后系统如何校验、落库、通知教师，最后给出效果截图并说明测试用例结果。这样写出来的内容既有深度又不会显得假大空。
5.2 调试文档的价值比想象中更大
你们可别小看调试文档。我接过好几个这类项目的售后，让我体会最深的是：一个环境搭不起来，比十行代码bug更让人崩溃。调试文档的核心目标是让一个从未接触过项目的人，能在30分钟内把系统跑起来。
我的调试文档通常包含这几块：开发环境清单（JDK版本、Maven版本、MySQL版本、Node版本）；初始化数据库的完整步骤；application.yml的核心配置说明；启动后端和前端的具体操作；默认测试账号列表；常见启动报错及处理办法。这里单独提醒一下，application.yml里如果你配置了spring.datasource.username和password，调试文档里建议换成测试环境的弱口令或者说明需要修改。有的同学把服务器上真实的数据库密码写进文档发出去，这个习惯很不好，要养成敏感信息脱敏的习惯。
5.3 答辩现场的加分与减分事项
最后说答辩。这一部分可能比代码本身还重要。答辩老师必然要问的问题我列几个：为什么选择这个选题？系统有哪些亮点和不足？如何保证并发场景下不超选？用户权限是怎么控制的？SSM和SpringBoot的区别是什么？第三个问题就是展示你的行锁方案和唯一索引，第四个展示拦截器设计，第五个用一句话概括——SpringBoot是对Spring家族的再封装，简化了配置，提高了开发效率，但底层核心机制还是Spring的IoC和AOP。这些问题提前准备好回答话术，现场就不会卡壳。
很多同学容易在演示环节翻车。我见过一个同学打开前端页面，现场网络波动导致静态资源加载失败，页面白屏，只能站在那里等。防范措施很简单，演示前把所有静态资源和依赖检查一遍，确认本地能稳定运行；另外记得提前把常用功能在演示数据上跑通一遍。关闭浏览器插件、清理无用的弹窗、把页面调整到合适的缩放比例，这些细节能让你在现场演示时表现得非常专业。还应该准备好一两个"意外预案"，比如登录失效了怎么快速重新登录。
6. 一次完整的开发上线实践顺序参考
最后给打算照这个方向动手的同学一个时间线参考。很多人拿到题目先急着写代码，结果后期反复返工。按我自己的经验，合理的顺序是：
第一步，用一天时间理顺业务流程，画出用例图和核心状态流转图。第二步，用一天到两天完成数据库设计，反复确认字段和三张核心表的关联关系，把状态字段的枚举值罗列成文档。第三步，搭建SpringBoot项目骨架，先不写业务，确保一个空项目能启动，写一个UserMapper验证数据库连通。第四步，先做登录接口和拦截器，这是所有功能的前置。第五步，做管理员模块——用户管理、题目审核、公告管理。第六步，做教师模块——题目发布、选题审核。第七步，做学生模块——题目浏览、选题申请、撤销。第八步，整体联调，测试核心流程的完整闭环。第九步，写调试文档、准备测试数据。最后，开始写论文初稿，并把论文中画好的图补充到设计文档里。
每个模块内部再遵循一个"最小可运行"原则：先让接口返回静态数据，再接入数据库，最后补充校验和异常分支。这样每一步都能看到阶段性成果，做起来不会慌。
结尾的个人经验
做这类选题管理系统，我最大的体会是：它比CRUD多走了一步，比真正的分布式系统又简单了很多，它卡在"刚好能体现一个毕业生系统设计能力"的位置上。老老实实把状态流转、权限控制、并发防超选这几件事想清楚，已经足够在答辩时交出漂亮的答卷。最后分享一个小技巧：把你在开发过程中遇到的各个报错记录下来，连同解决办法一起收集在问题排查文档里，这部分内容放论文第六章和调试文档里都很好用。哪怕只是简单列一个"报错信息+原因+解决方式"的表格，也能体现出你实实在在动手写过代码。真到了答辩现场，老师最怕的就是听到"照着视频敲的，没遇到过问题"这种话，你自己排查过多少问题、踩过多少坑，其实几句话就能听出来。
