Java毕业设计选题系统实战：Spring Boot+MyBatis-Plus实现双向选择与防超卖

简介：这是一套面向高校计算机相关专业学生的Java毕业设计论文选题系统，适合正在准备毕业设计、需要完成选题管理类课题的本科生与指导教师参考。系统围绕选题展示、学生申请、教师审核、选题分配、选题讨论与进度管理等环节展开，覆盖从选题到过程跟踪的完整流程，可作为课程设计或毕业设计的实战参考方案。资源包共1304个文件，包含256个html页面、226个css样式、215个js脚本、85个jsp页面，以及47个java源码、49个class编译文件、42个jar依赖和33个xml配置，另含185个png、95个gif等图片素材与sql脚本，压缩包约19.05MB，前后端结构完整、层次清晰。目前已有162人学习下载。读者可从中获取可运行的选题系统源码、数据库脚本与页面模板，理解控制器分层、权限审核与进度记录等模块的实现思路，便于二次开发与论文撰写。

1. 从一份“选题系统”说起：Java 毕业设计里最容易被低估的工程题

每年到了毕业季，计算机专业的群里总会出现两种极端：一种是学生追着老师问“还有什么题目能选”，另一种是老师对着几十份重复的“图书管理系统”“学生成绩管理系统”发愁。论文选题系统看起来只是把题目从纸上搬到网页上，但它背后牵扯的东西比想象中多——角色权限、选题批次、双向选择、冲突检测、状态流转，每一个点都能让一个只会写增删改查的 Java 新手翻车。我带过几届学生的课程设计和毕业设计，也帮同事评审过类似系统，发现真正能跑通“学生选、教师审、管理员控”这条完整链路的不到三成。这篇文章就围绕 Java 学生毕业设计论文选题系统这个具体方向，把需求拆解、技术选型、核心表结构、关键接口和部署验证一步步讲清楚。适合正在做毕业设计选题的本科生、需要带课程设计的助教，以及想用真实业务练手的 Java 初学者。读完你至少能判断：这个系统值不值得做、怎么做才不烂尾、哪些坑必须提前绕开。

2. 选题系统到底在解决什么问题：角色、状态与冲突模型

2.1 三类角色和一条选题生命周期

很多同学一上来就画 ER 图，结果画到一半发现“教师能不能替学生选”“管理员能不能改已确认的选题”这类问题根本没想清楚。我一般会先把角色和状态机定下来，再动数据库。

选题系统里通常有三类角色：

• 学生：浏览题目、提交志愿、查看结果、退选或改选（在允许的时间窗口内）。
• 教师：发布题目、设置名额、审核学生申请、确认或拒绝。
• 管理员：管理批次、导入用户、监控选题进度、处理异常数据。

一条完整的选题生命周期大致是：教师出题 → 管理员审核题目 → 学生提交志愿 → 教师确认 → 系统锁定结果。中间任何一个环节都可能出现并发冲突，比如两个学生同时抢最后一个名额，或者教师已经确认了 A 学生，B 学生还在提交申请。

提示：不要一上来就写代码，先用纸把状态流转画出来，后面写 Service 层会轻松很多。

2.2 为什么“双向选择”比“先到先得”更难写

先到先得只需要一个计数器，谁先点谁拿走。但真实的教学场景里，教师希望看到所有申请再决定，学生也希望填多个志愿。这就变成了一个带优先级的双向匹配问题。

常见做法是给学生的志愿加一个priority字段，教师端按志愿顺序和提交时间排序，再手动确认。系统层面要保证的是：同一个学生不能被两个教师同时确认，同一个教师的名额不能被超额确认。

这里就涉及 Java 里最基础但也最容易写错的东西——事务和锁。很多同学用synchronized或者数据库的select ... for update，但没考虑 Spring 事务的传播行为，结果测试时没问题，一上并发就超卖。

2.3 技术选型：为什么我建议 Spring Boot + MyBatis-Plus + MySQL

毕业设计选题系统的业务复杂度不高，但要求稳定、好调试、方便答辩时讲清楚。我一般会推荐这套组合：

如果时间紧，前端可以用 Vue 3 的 CDN 引入方式，不搭 Node 环境，直接写在 HTML 里。这样部署时只需要一个 Jar 包，答辩演示不容易出环境问题。

2.4 核心表结构：五张表就能跑通主流程

不要一上来就设计十几张表。我一般会先建这五张，后面缺什么再加：

-- 用户表，用 role 区分学生、教师、管理员 CREATE TABLE `sys_user` ( `id` bigint NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '学号或工号', `password` varchar(100) NOT NULL COMMENT 'BCrypt 加密', `real_name` varchar(50) DEFAULT NULL, `role` varchar(20) NOT NULL COMMENT 'STUDENT/TEACHER/ADMIN', `class_name` varchar(50) DEFAULT NULL COMMENT '学生班级', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 选题批次，控制时间窗口 CREATE TABLE `topic_batch` ( `id` bigint NOT NULL AUTO_INCREMENT, `batch_name` varchar(100) NOT NULL, `start_time` datetime NOT NULL, `end_time` datetime NOT NULL, `status` tinyint NOT NULL DEFAULT '0' COMMENT '0未开始 1进行中 2已结束', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 题目表 CREATE TABLE `topic` ( `id` bigint NOT NULL AUTO_INCREMENT, `title` varchar(200) NOT NULL, `description` text, `teacher_id` bigint NOT NULL, `batch_id` bigint NOT NULL, `max_students` int NOT NULL DEFAULT '1', `selected_count` int NOT NULL DEFAULT '0', `status` tinyint NOT NULL DEFAULT '0' COMMENT '0待审核 1已发布 2已满 3已关闭', PRIMARY KEY (`id`), KEY `idx_teacher` (`teacher_id`), KEY `idx_batch` (`batch_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 学生志愿表 CREATE TABLE `student_choice` ( `id` bigint NOT NULL AUTO_INCREMENT, `student_id` bigint NOT NULL, `topic_id` bigint NOT NULL, `priority` int NOT NULL DEFAULT '1' COMMENT '志愿顺序', `status` tinyint NOT NULL DEFAULT '0' COMMENT '0待处理 1已确认 2已拒绝', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_student_topic` (`student_id`,`topic_id`), KEY `idx_topic` (`topic_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 最终选题结果，用于锁定 CREATE TABLE `final_selection` ( `id` bigint NOT NULL AUTO_INCREMENT, `student_id` bigint NOT NULL, `topic_id` bigint NOT NULL, `teacher_id` bigint NOT NULL, `confirm_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_student` (`student_id`), UNIQUE KEY `uk_topic_student` (`topic_id`,`student_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这几张表的逻辑说明：sys_user用role字段做粗粒度权限，够用且好维护；topic_batch控制时间窗口，避免学生半夜偷偷选；topic里的selected_count是冗余字段，用来快速判断是否满员，但必须配合事务更新；student_choice记录志愿，final_selection记录最终结果，两者分开是为了保留过程数据，答辩时能展示“为什么选了他没选你”。

参数上要注意：max_students默认给 1，但有些教师想带 2-3 人，这个字段要允许修改。selected_count的更新一定要放在@Transactional里，并且用update topic set selected_count = selected_count + 1 where id = ? and selected_count < max_students这种带条件的 SQL，靠数据库行锁保证不超卖。

3. 用 Spring Boot 把选题主流程跑通：接口、事务与并发控制

3.1 项目骨架和依赖配置

我一般用 Spring Initializr 生成骨架，选 Spring Web、MyBatis-Plus、MySQL Driver、Lombok、Spring Security。如果不想用 Security，也可以先用拦截器做简单权限，但答辩时容易被问“怎么防越权”，所以建议还是上 Security。

<!-- pom.xml 关键依赖 --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency>

application.yml里把数据库连接和 MyBatis-Plus 的日志打开，方便调试：

spring: datasource: url: jdbc:mysql://localhost:3306/topic_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

这里serverTimezone必须写，否则 MySQL 8 会报时区错误。log-impl打开后控制台会打印 SQL，调事务的时候一眼就能看出有没有生效。

3.2 学生提交志愿的接口与防重复提交

学生提交志愿看起来简单，但有两个坑：一是重复提交同一题目，二是并发提交多个志愿时顺序错乱。我的做法是用student_choice表的唯一索引uk_student_topic兜底，同时在 Service 层加一个简单的分布式锁（如果单机就用synchronized或 Redis 锁）。

@Service public class ChoiceService { @Autowired private StudentChoiceMapper choiceMapper; @Autowired private TopicMapper topicMapper; @Transactional(rollbackFor = Exception.class) public void submitChoice(Long studentId, Long topicId, Integer priority) { // 1. 检查批次是否在进行中 Topic topic = topicMapper.selectById(topicId); if (topic == null || topic.getStatus() != 1) { throw new BizException("题目不可选"); } // 2. 检查是否已选过该题 Long count = choiceMapper.selectCount( new LambdaQueryWrapper<StudentChoice>() .eq(StudentChoice::getStudentId, studentId) .eq(StudentChoice::getTopicId, topicId) ); if (count > 0) { throw new BizException("请勿重复提交"); } // 3. 插入志愿，唯一索引兜底 StudentChoice choice = new StudentChoice(); choice.setStudentId(studentId); choice.setTopicId(topicId); choice.setPriority(priority); choice.setStatus(0); choiceMapper.insert(choice); } }

逻辑说明：先查题目状态，再查是否重复，最后插入。虽然查重和插入之间有空窗期，但唯一索引uk_student_topic会在数据库层拦截重复数据，抛出的DuplicateKeyException可以在全局异常处理器里转成友好提示。参数上，priority建议限制在 1-5 之间，前端做校验，后端也做一次。

3.3 教师确认选题：用条件更新防止名额超卖

这是整个系统最容易翻车的地方。两个学生同时申请最后一个名额，如果先查selected_count再更新，必然超卖。正确做法是用一条带条件的 UPDATE：

@Transactional(rollbackFor = Exception.class) public void confirmStudent(Long teacherId, Long choiceId) { StudentChoice choice = choiceMapper.selectById(choiceId); if (choice == null || choice.getStatus() != 0) { throw new BizException("该申请不存在或已处理"); } Topic topic = topicMapper.selectById(choice.getTopicId()); if (!topic.getTeacherId().equals(teacherId)) { throw new BizException("无权操作该题目"); } // 关键：条件更新，只有未满员才能加一 int updated = topicMapper.update(null, new LambdaUpdateWrapper<Topic>() .eq(Topic::getId, topic.getId()) .lt(Topic::getSelectedCount, topic.getMaxStudents()) .setSql("selected_count = selected_count + 1") ); if (updated == 0) { throw new BizException("该题目名额已满"); } // 更新志愿状态 choice.setStatus(1); choiceMapper.updateById(choice); // 写入最终结果 FinalSelection fs = new FinalSelection(); fs.setStudentId(choice.getStudentId()); fs.setTopicId(choice.getTopicId()); fs.setTeacherId(teacherId); finalSelectionMapper.insert(fs); }

这段代码的核心是lt(Topic::getSelectedCount, topic.getMaxStudents())，它会被翻译成where selected_count < max_students，配合 InnoDB 的行锁，保证并发下不会超卖。如果updated == 0，说明名额已满，直接抛异常回滚。注意final_selection表的uk_student唯一索引，防止一个学生被两个教师同时确认。

3.4 管理员监控接口：用 SQL 聚合看选题进度

管理员需要一眼看到哪些题目没人选、哪些学生还没选。这种统计用 MyBatis-Plus 的 Wrapper 写起来很啰嗦，直接写 XML 更清晰：

<select id="selectTopicProgress" resultType="map"> SELECT t.id, t.title, u.real_name AS teacherName, t.max_students AS maxStudents, t.selected_count AS selectedCount, (SELECT COUNT(*) FROM student_choice sc WHERE sc.topic_id = t.id AND sc.status = 0) AS pendingCount FROM topic t LEFT JOIN sys_user u ON t.teacher_id = u.id WHERE t.batch_id = #{batchId} ORDER BY t.selected_count ASC </select>

这个查询返回每个题目的已选人数和待处理申请数，管理员按selected_count升序看，就能快速发现冷门题目。参数batchId从当前进行中的批次取，避免看历史数据。

注意：子查询在数据量大时会慢，但毕业设计的数据量通常几百条，完全够用。如果非要优化，可以加冗余字段或定时任务，但没必要。

4. 避坑与排查：选题系统上线前必须过的五道坎

4.1 现象：学生提交志愿后页面报 500，日志显示 DuplicateKeyException

原因：唯一索引uk_student_topic拦截了重复提交，但全局异常处理器没捕获，直接抛到前端。

解决：在@RestControllerAdvice里加一个DuplicateKeyException的处理，返回“请勿重复提交”而不是 500。同时前端提交按钮点击后置灰，防止连点。

4.2 现象：教师确认后，学生端看到的还是“待处理”

原因：student_choice的status更新了，但前端查询用的是缓存数据，或者查询条件没带status。

解决：确认接口返回后，前端强制刷新列表；后端查询志愿列表时，把status字段返回给前端，让前端根据状态渲染不同按钮。不要依赖前端缓存。

4.3 现象：两个教师同时确认同一个学生，都提示成功

原因：final_selection表的uk_student唯一索引没建，或者建了但代码里没捕获异常。

解决：建表时加上UNIQUE KEY uk_student (student_id)，并在确认逻辑里捕获DuplicateKeyException，提示“该学生已被其他教师确认”。这个坑我见过至少三次，每次都是表结构没设计好。

4.4 现象：批次结束后，学生还能提交志愿

原因：只在前端隐藏了按钮，后端没校验批次时间。

解决：在submitChoice方法里加一段：

TopicBatch batch = batchMapper.selectById(topic.getBatchId()); if (batch.getStatus() != 1 || LocalDateTime.now().isAfter(batch.getEndTime())) { throw new BizException("当前不在选题时间内"); }

时间判断用LocalDateTime，不要用Date，避免时区问题。batch.getStatus()也要判断，防止管理员手动关闭批次后还能提交。

4.5 现象：部署到服务器后，上传的题目附件下载 404

原因：本地开发时文件存在D:/upload，服务器上没这个目录，或者 Nginx 没配静态资源映射。

解决：把文件存储路径配成相对路径或可配置项，在application.yml里写file.upload-path: /data/upload/，启动时检查目录是否存在，不存在就创建。如果用了 Nginx，加一条location /upload/ { alias /data/upload/; }。这个坑不涉及代码逻辑，但答辩演示时文件下载失败很尴尬。

5. 让选题系统经得起追问：并发压测、数据一致性校验与答辩技巧

走到这里，系统基本能跑了。但答辩时老师最喜欢问的就是“如果很多人同时选怎么办”“你怎么保证数据一致性”。我的习惯是提前做两件事：一是用 JMeter 或 Postman 的 Runner 做一轮并发测试，二是写一个对账接口，随时校验数据。

并发测试不用太复杂，开 50 个线程同时调确认接口，看selected_count会不会超过max_students。如果超了，回头检查 SQL 是不是漏了lt条件。我一般会在测试环境跑一遍，把结果截图放在答辩 PPT 里，比空口说“我用了事务”有说服力。

数据一致性校验接口可以这样写：

@GetMapping("/checkConsistency") public Map<String, Object> checkConsistency() { Map<String, Object> result = new HashMap<>(); // 检查 topic.selected_count 是否等于 final_selection 的实际数量 List<Topic> topics = topicMapper.selectList(null); List<String> errors = new ArrayList<>(); for (Topic topic : topics) { Long actual = finalSelectionMapper.selectCount( new LambdaQueryWrapper<FinalSelection>() .eq(FinalSelection::getTopicId, topic.getId()) ); if (!actual.equals(topic.getSelectedCount().longValue())) { errors.add("题目 " + topic.getId() + " 计数不一致：冗余=" + topic.getSelectedCount() + "，实际=" + actual); } } result.put("errors", errors); result.put("totalTopics", topics.size()); return result; }

这个接口在答辩演示时可以直接调，如果返回空列表，说明数据没问题。如果真有差异，也能快速定位是哪张表更新漏了。参数上不需要额外配置，直接查全表，数据量小的时候秒出结果。

另外一个小技巧：把student_choice和final_selection的create_time、confirm_time都保留，答辩时如果老师问“怎么证明这个学生是先选的”，直接按时间排序展示。这些细节不增加多少代码量，但能让系统看起来更完整。

最后说一个我自己的教训。第一次做这类系统时，我觉得“双向选择”太麻烦，直接改成了先到先得，结果教师端没法筛选学生，被带课老师要求重做。后来老老实实把志愿优先级和教师确认加回来，虽然多写了两天，但答辩时老师问“如果两个学生都优秀怎么办”，我可以直接演示教师端按志愿顺序和提交时间排序，然后手动确认。这个功能不复杂，但它是选题系统和普通增删改查的分水岭。希望帮到你。

本文还有配套的精品资源，点击获取