又是一年毕设季后台私信里被问得最多的就是“Java Web 的选题还能做什么”。说实话纯增删改查的“XX管理系统”早就让学生和答辩老师都审美疲劳了。今天分享的这个选题——基于 Web 的智能选择系统算是我带过那么多届毕设里性价比极高的一个既有 Web 开发该有的页面、交互、CRUD又能在“智能”二字上做出差异化和技术亮点不至于被评委一句“这不就是个信息管理系统吗”怼到无言以对。这篇文章我会把当时从需求拆解、数据库设计、核心技术实现到调试部署的整个链路都整理出来给正在纠结选题和已经选了类似题目的同学一个可以直接上手的参考。先说清楚它“智能”在哪、解决什么问题。传统的选课系统大多只是“列出课程然后人肉抢”并发一高就各种超卖和错乱。智能选择系统要做的是根据学生的基础信息、选课意愿和课程容量自动进行冲突检测、资格校验、优先级分配甚至支持超选课程的多志愿抽签以及候补提醒。用大白话说别人做的是“登记表”你做的是“一个会做判定的分发器”。这个定位用在毕设里既能展示完整的业务流程又能往上写不少有价值的实现细节。适合谁来参考Java Web 方向但不想只做管理系统的同学、需要源码加文档的应届生、以及想给自己的项目加实时推送、并发控制等亮点但不知道从何处下手的初学者。下面我会按当时项目从 0 到 1 的真实开发顺序展开中间穿插大量踩坑记录和答辩准备方向篇幅不短建议先收藏再慢慢看。1. 从“选择”到“智能选择”需求拆解与功能边界很多同学拿到题目就急着建表写代码结果写到一半发现业务逻辑根本撑不起“智能”两个字。这个系统的核心不是课程 CRUD而是选课规则引擎。我先把需求拆成四个独立模块来说明边界方便你后面设计表结构和接口时对号入座。1.1 核心角色与主流程系统按用户角色划分典型角色是学生、教师、管理员。学生负责浏览课程、提交选课志愿、查看结果和课表教师负责上报开课计划、查看自己课程的选课名单管理员负责维护基础数据、配置选课批次、审核课程和发布结果。整个主流程可以简化为管理员发布选课批次 → 学生根据批次时间提交志愿 → 系统按照预设规则完成分配 → 发布结果并支持候补和退选。这里有个关键设计决策“智能”分配不一定发生在学生提交的瞬间更多是在批次结束后统一跑批量算法。如果边提交边分配遇到热门课会变成纯拼手速这既不公平也不“智能”。所以我建议把“提交志愿”和“结果确认”解耦成两个阶段这也是答辩时可以重点讲解的设计亮点。1.2 智能选课逻辑的三个核心功能点第一个是资格校验。得在提交前判断学生是否满足选课前提比如是否已经修过先修课程、是否符合年级限制、是否已经选过同组课程。别小看这条链路它涉及多张表的联合查询也是后面“为什么不能只在 Service 层硬写 if”的典型例子。第二个是冲突检测。系统得检查学生提交的几个志愿是否在上课时间上重叠。这是最容易出 bug 的地方因为哪怕数据库里存的是“周一 3-4 节”前端的字符串比较也不一定准确更别说跨校区上课时间不同步的情况。建议建立独立的上课时间表用“星期 节次区间”作为原子单位来判断重叠。第三个是优先级分配与抽签。通常的做法是容量充足的课程直接按志愿顺序分配容量不足时按学生高年级优先、平均绩点优先、志愿次序优先等规则排序超出部分进入候补队列。这个排序逻辑最好做成可以配置的形式因为毕设答辩中经常有老师会问到“如果我临时调整规则怎么办”。我当时的做法是引入一个很轻量的规则权重表把每个维度作为一条记录存起来后端统一解析处理演示的时候直接改数据库就能切换策略。1.3 哪些功能不该做——边界管理毕设时间精力有限别让需求蔓延。我见过有人把聊天室、论坛、消息通知都塞进选课系统结果到答辩前还没跑通主流程。当时我划定的“不做清单”是不做复杂的学分绩点计算系统、不做移动端 App、不做线上支付、不做细粒度权限框架。保留一个实时提醒模块就够了最好基于 WebSocket 做“选课结果已发布”的站内推送这是性价比最高的功能亮点。2. 数据库设计一张“选择结果表”如何撑起整套规则数据库是整个项目的地基也是最容易被答辩老师抓住问细节的地方。我见过很多失败案例——把选课关系直接存成“学生表里的一个课程字段”或者干脆没有中间状态字段。这套系统里选课记录表course_selection才是真正的主角它的字段设计直接决定了智能分配能否优雅实现。2.1 核心表结构一览我按当时竣工项目的最终版表结构整理出这些核心表字段说明已经标好表名核心字段用途说明studentid, student_no, name, grade, major_id学生基础信息附带年级和绩点字段teacherid, teacher_no, name, department教师信息courseid, course_code, name, credit, capacity, selected_count课程基本信息与总容量course_scheduleid, course_id, weekday, start_section, end_section, campus课程的上课时间安排支持一门课多条course_prerequisiteid, course_id, pre_course_id先修课程的依赖关系selection_batchid, name, start_time, end_time, strategy_config选课批次的配置如起止时间course_selectionid, student_id, course_id, priority, status, assigned_at选课志愿与最终结果的落表waiting_queueid, selection_id, position候补队列记录其中course_selection表的status字段建议设置为0待处理、1选中、2候补、3已退选、4未选中。通过这个字段查询结果、批量分配、退选释放名额等操作都可以复用同一张表后面写 SQL 会非常舒服。2.2 冲突检测的最佳实践用区间判断而不是字符串拼接刚才提到时间冲突检测我强烈建议把course_schedule表独立出来用(weekday, start_section, end_section)表示一次上课时间。检测重叠的核心 SQL 逻辑就是对同一个学生所选的多个课程检查两两之间是否存在start_section 对方end_section AND end_section 对方start_section同时weekday相等。举个例子A 课程是周一第 1-2 节B 课程是周一第 3-4 节表面上看不重叠但如果数据库里存的是“周一上午”这种模糊字符串程序根没法算。用节次区间去判断SQL 写起来简单后面做批量算法校验也不容易出逻辑漏洞。2.3 外键要不要建我的建议是“用但不多”很多教学代码都能看到级联外键全都建起来但真实项目里外键用太死反而给并发写入制造锁竞争。我的个人做法是表结构设计时保留外键逻辑但建表时只建普通索引不加物理外键。理由有两个一是在course_selection这种高频写入表上物理外键会让数据库做额外的检查二是后面做批量分配时的批量更新语句外键存在会有一些不必要的约束干扰。不过逻辑关联必须清晰student_id、course_id上一定要建索引否则数据量一大选出结果的时间会让人崩溃。3. 技术栈选型SSM 还是 Spring Boot这不该是个纠结题关于技术栈标题既然写了 Java Web我默认读者是奔着SSMSpring Spring MVC MyBatis或者 Spring Boot 单体应用来的。当时我带项目用的主力是Spring Boot 2.7 MyBatis-Plus MySQL 5.7 Layui WebSocket。如果学校强制要求“SSM 架构”而你又想省心可以考虑 Spring Boot并在文档里写明它是在 SSM 基础上做了自动化配置演进——很多学校是接受这个解释的。3.1 为什么最终选择 Spring Boot 而不是“手写配置”理由很简单如果只是做个课程管理系统大部分时间都应该花在业务逻辑上而不是被 XML 配置追着跑。Spring Boot 的自动配置能让项目在十分钟内跑起来具体到写代码时还有几个实打实的收益spring-boot-starter-websocket一个依赖就解决实时通知不用手动引入一堆 jar 包内嵌 Tomcat 让本地调试和部署都用不着单独装容器application.yml集中写数据源、Redis、WebSocket 配置答辩演示环境出问题的概率小很多当然前提是你对 Spring 的 IOC/DI、Spring MVC 的请求流程、MyBatis 的 Mapper 映射这些基本概念要能讲清楚。哪怕自动配置帮你把对象装配好了老师问起来你照样要回答“Bean 是怎么实例化的”——别只会Autowired。3.2 前端选型Layui 还是 Vue?前端部分毕设系统不推荐上太重的脚手架。我当时直接用了 Layui jQuery页面表格、表单、弹窗都是现成组件颜值尚可关键是演示的时候不容易白屏。如果你对 Vue 很熟也可以上 Vue 3 Vite Element Plus然后由后端提供 JSON 接口。只是要注意如果前端工程和后端分开部署答辩前一定要提前检查跨域配置别让一个 CORS 错误毁掉整场演示。3.3 一个容易被忽视的依赖bootstrap-plus / 分页插件列表页分页是一个加分项。MyBatis-Plus 自带分页插件只需要在项目里放一个MybatisPlusInterceptor配置类然后把PaginationInnerInterceptor加进去即可。没有这个配置时你写selectPage会发现LIMIT不生效返回全表数据。这是典型的“配置没配全代码看起来没错”的坑我后面会再次提到。4. “智能分配”核心逻辑实现抽签排序和并发控制的完整代码思路这一节是整篇文章技术含金量最高的部分。很多同学做选课系统只会做到“点击某一门课然后插入一条记录”这跟智能差的不是一星半点。我当时用了十几天的课余时间专门打磨这段分配逻辑最终代码也不复杂但思考过程值得完整分享。4.1 批量分配算法基于优先级的排序 容量占用模拟当批次结束后系统会对该批次下所有status 0的志愿记录统一运行分配算法。伪代码如下// 分配算法核心思路伪代码 public void runAllocation(Long batchId) { // 1. 查出该批次下所有待处理志愿按批次策略字段排序 ListSelectionRecord records selectionMapper.selectPending(batchId); // 2. 按课程分组方便逐门课处理容量 MapLong, ListSelectionRecord groupByCourse records.stream() .collect(Collectors.groupingBy(SelectionRecord::getCourseId)); for (Map.EntryLong, ListSelectionRecord entry : groupByCourse.entrySet()) { Long courseId entry.getKey(); Course course courseMapper.selectById(courseId); // 3. 对同一门课的所有志愿做优先级排序 ListSelectionRecord sorted entry.getValue(); sorted.sort(Comparator .comparing(SelectionRecord::getPriority) // 志愿顺序越前越优先 .thenComparing(SelectionRecord::getGrade, Comparator.reverseOrder()) .thenComparing(SelectionRecord::getGpa, Comparator.reverseOrder())); // 4. 前 capacity 个标记为已选中其余进入候补队列 int available course.getCapacity() - course.getSelectedCount(); for (int i 0; i sorted.size(); i) { SelectionRecord r sorted.get(i); if (i available) { r.setStatus(1); // 选中 } else { r.setStatus(2); // 候补 // 同时插入 waiting_queue 表position 为 i - available } } selectionMapper.batchUpdateStatus(sorted); } }这个版本可以满足基础的“智能选择”需求。但答辩时如果老师追问“同一志愿顺位下绩点和年级哪个优先”那就要回到strategy_config里的策略配置去说明。我的建议是不要把它写死到代码里而是拆成若干个Comparator组合让规则表决定优先级顺序。比如配置表里存grade_weight10, gpa_weight5代码动态取权重排序这样才算真正把规则抽离出来。4.2 并发抢课怎么处理同一瞬间两个人抢最后一个名额这也是热门考核点。最简单可靠的方案是使用数据库行锁 原子更新-- 伪 SQL展示如何在更新时校验并扣减容量 UPDATE course SET selected_count selected_count 1 WHERE id #{courseId} AND selected_count capacity;注意这里的selected_count capacity是原子更新的关键。如果更新结果影响行数为 0说明已满再给用户提示。比起“先查后改”再 upsert这种原子更新的方案即使在并发下也不会超卖。当然如果你引入了 Redis也可以使用DECR/INCR做前置计数但 Redis 和 MySQL 数据一致性还需额外处理。毕设场景下数据库原子更新 唯一索引保证已经足够讲清楚并发安全不需要硬上分布式锁。唯一索引也很关键给course_selection表加上(student_id, course_id, batch_id)的唯一索引可以防止学生重复提交同一门课的志愿。否则万一业务代码漏了查重就会出现两个 status 同时为 1 的记录。4.3 WebSocket 实时提醒从“学生自己刷新”到“系统推给用户”选课结果发布后如果让学生一个劲地刷新页面体验很差。我在系统里集成了 WebSocket把“结果已发布”“候补转正”这类事件推送给在线学生。核心配置是三步第一步引入依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-websocket/artifactId /dependency第二步写配置类和端点。主要注册一个/ws/selection的 WebSocket 端点握手阶段从查询参数里解析出userId并存入会话属性。第三步推送消息。在分配逻辑跑完后的 Service 方法里向SimpMessagingTemplate发送消息到指定用户messagingTemplate.convertAndSendToUser( String.valueOf(studentId), /topic/selectionResult, {\message\:\你的选课结果已发布请查看\,\type\:\RESULT\} );前端用一个原生 WebSocket 或stompjs客户端监听对应地址弹出消息提示并自动刷新页面表格。提示WebSocket 在跨域和反向代理环境下很容易出连接失败的问题。如果你是在本机演示地址直接写ws://localhost:8080/ws/selection即可。如果部署到服务器记得在 Nginx 里配置proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection upgrade;否则浏览器一直接不上。5. Mapper 与 SQL 的“隐形坑”从自动映射失效到分页失效很多毕设代码看起来没问题跑起来几百条数据也不出错但偏偏在答辩演示的关键时刻翻车。我把自己踩过的一类典型问题拿出来拆解这些坑很隐蔽尤其容易出现在 MyBatis 这种半自动 ORM 上。5.1 驼峰映射数据库下划线字段为何返回 null如果数据库字段是student_name实体属性是studentName而 MyBatis 没有开启驼峰映射那么查询出来的studentName就是 null。这个问题在 Spring Boot 配置里只需要一行mybatis: configuration: map-underscore-to-camel-case: trueMyBatis-Plus 默认是开启了这个映射的但如果你是手写 SSM 整合非常容易漏掉。每次答辩前可以用一个简单的接口测一下返回 JSON 里的字段是否齐全别等演示到一半才发现。5.2 分页插件的两处经典失效第一次使用 MyBatis-Plus 分页功能的人有极高概率犯这个错误直接new Page(1, 10)作为参数传给selectPage结果页码始终没有生效。原因十有八九是没有配置分页拦截器。我直接给出可用的配置类代码Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }另一个失效场景是如果你在 XML 里手写了一个多表联查的select语句并且返回IPage但实际上 SQL 没有套上LIMIT那是因为你的 count 查询和多表分页逻辑没有被正确拦截。建议手写多表分页时直接用${ew.customSqlSegment}或手动拼LIMIT #{page.offset}, #{page.size}不要依赖拦截器的“自动猜测”。5.3 用 explain 检查慢查询选课分配批次跑完如果数据量过万需要留意查询性能。答辩时老师很可能问“如果有一万人同时选课你的系统会卡吗”。你可以提前在本地压一批测试数据用EXPLAIN看执行计划确保course_selection表的查询命中了student_id和course_id的索引。然后大方地说这里建立了联合索引并且分配逻辑在批量阶段处理而不是在用户点击瞬间逐条处理能扛住常规并发场景。这样答比支支吾吾要好得多。6. 调试运行与部署从本地跑通到服务器演示的完整链路这个章节写给所有“明明在我电脑上能运行”却一到演示就翻车的朋友。别小看环境问题毕业答辩翻车十有八九是一小时前才发现数据库连不上。6.1 本地开发环境准备清单建议用统一版本避免各种诡异兼容问题。我当时的配置如下JDK 1.8想装新项目用 JDK 17 也行但 Maven 里spring-boot-maven-plugin要配套Maven 3.6本地仓库有阿里云镜像否则下载依赖等到怀疑人生MySQL 5.7尽量别用 MySQL 8.0 的 caching_sha2_password 认证插件老驱动连不上会报 Unable to load authentication pluginNavicat 或 DataGrip用来执行建表脚本和看数据IntelliJ IDEA 2021装 Lombok 插件一个特别容易致命的问题是时区配置。连接串里一定要加上serverTimezoneAsia/Shanghai否则你插入datetime时会出现“时间差 8 小时”或者直接连不上。6.2 启动流程与常见启动失败排查项目启动步骤很简单建库 → 执行init.sql→ 修改application.yml里的数据库账号密码 → 启动Application.java→ 浏览器访问http://localhost:8080。但以下三种启动失败值得提前排查第一端口被占用。8080被其他进程占了Spring Boot 启动会直接报Port already in use。解决方式是找到占用进程或者临时把server.port改成8081。第二数据库连接失败。如果报Unknown database说明建的库名配置文件里对不上如果是Access denied检查用户名密码是否有特殊字符url里要不要加编码。如果是用 Docker 跑的 MySQL还得注意容器端口有没有映射到宿主机。第三mapper 找不到。报Invalid bound statement (not found)多半是MapperScan扫描路径没有覆盖 Mapper 接口所在包或者 XML 文件没有被 Maven 打包到target/classes下。后者经常发生在 XML 放在src/main/java里时没有在pom.xml里声明resources。6.3 Linux 服务器部署把项目打包成 jar 上传运行如果答辩要用远程服务器演示最省心的方式是打包成可执行 jar。关键步骤# 在项目根目录执行跳过测试 mvn clean package -DskipTests # 上传到服务器后后台启动 nohup java -jar selection-system.jar --spring.profiles.activeprod app.log 21 # 查看日志有没有报错 tail -f app.log生产环境建议单独建一个application-prod.yml把数据库地址换成云数据库的内网地址或外网地址。注意服务器防火墙和安全组要放行8080端口否则页面访问不到。这一条在阿里云/腾讯云里操作位置不同我建议提前一天演练一遍别等到答辩早上才去开端口。7. 常见错误排雷与答辩准备把这些细节背下来稳过基本没悬念最后这部分我根据这些年看过的答辩现场和学生们反馈最多的翻车点做一个问题清单。它既是排雷手册也是答辩时老师最爱问的“送分题”集合。7.1 高频报错与解决方案速查表报错信息常见原因解决方案Port already in use: 8080端口被占换端口或杀进程Access denied for user数据库账号密码错误检查application.ymlUnable to load authentication plugin caching_sha2_passwordMySQL 8.0 认证问题改用 5.7或升级驱动Invalid bound statement (not found)Mapper 扫描/XML 未打包检查MapperScan和pom resourcesFailed to configure a DataSource没有数据源配置确保连接串正确Table doesnt exist忘记建表/库名不对执行建表脚本核对库名WebSocket 连不上跨域/反向代理未升级协议配置 ws 代理或直接本机演示数据中文乱码字符集不一致连接串加characterEncodingutf8表改 utf8mb47.2 答辩时如何把“智能”讲得更有说服力准备一小段“技术亮点”话术从以下三个角度展开会比干巴巴照着 PPT 念更容易拿高分设计层面选课提交与结果分配分离通过批次配置支持不同分配策略规则可动态切换而不是写死逻辑。数据层面用独立时间表表达上课时间冲突检测可计算、可验证数据库层通过唯一索引和原子更新保障数据一致性。体验层面通过 WebSocket 将结果实时推送给学生候补队伍自动释放、自动递补而不是让学生反复刷新页面。如果老师真的问到“高并发怎么处理”可以从“数据库原子更新 唯一索引 批次算法异步化”三条线回答顺势提一句“如果继续扩展可以引入 Redis 做预扣库存和消息队列削峰”点到即止即可。切记不要过度吹嘘自己没用过的技术被追问底层细节时很容易露馅。7.3 我的个人体会源码、文档和演示的优先级排序最后说说我给每个毕设项目的实际分配比例核心功能代码占 50%数据库设计占 20%演示准备占 20%文档占 10%。很多同学文档写了一大堆代码却调不通这是本末倒置。我的习惯是先在本地把核心链路跑通——学生登录、浏览课程、提交志愿、管理员跑分配、结果发布、WebSocket 提醒这条链路完整跑通后再开始补文档和 PPT。因为只要核心链路通了文档里画流程图、写系统设计都会顺手得多反过来文档写得再漂亮一运行就报错老师的第一印象直接就崩了。如果你是自己独立做这个选题建议按照“需求拆解 → 建库跑通一条主流程 → 加智能分配 → 加实时提醒 → 补界面细节和异常处理”的顺序推进。前六周主攻功能后面两周专门练演示环境包括试一次从零启动项目、试一次断网/断电恢复这些细节往往比你以为的更能决定最终成绩。