毕业设计实战：基于Spring Boot+微信小程序的大学生选修选课系统全流程指南毕业设计实战：基于Spring Boo

毕业设计实战：基于Spring Boot+微信小程序的大学生选修选课系统全流程指南

在开发"大学生选修选课系统"的过程中，选课时间冲突检测与容量控制曾是最大的技术难点。初期我们未设计"选课限制表"与"排课时间冲突检测算法"，导致学生可以同时选修两个时间重叠的课程，甚至超选学分上限，系统上线第一天就出现了37个冲突选课记录😨。我们花费了整整3天时间重构数据库表结构和业务逻辑，才彻底解决了这个核心问题。基于此次实战经验，本文将系统拆解从需求分析、技术选型、功能实现到测试验收的全流程关键要点，为筹备"选课系统"类毕设的同学提供可落地的实施指南。

一、需求分析：聚焦校园选课核心痛点，避免功能冗余返工

很多同学在设计选课系统时容易陷入"大而全"的思维，试图加入"在线课堂"、"社交互动"、"智能推荐"等复杂模块。我们最初也规划了"课程评价社区"和"智能课程推荐算法"，但经与导师讨论发现，这些功能严重偏离了"课程管理、选课限制、成绩管理"三大核心诉求，导致前期原型设计大量返工。明确"用户角色-核心功能"的对应关系，是降低返工率的关键前提。

1. 核心用户与功能拆解（优化后的三元角色体系）

系统核心用户分为管理员、教师、学生三类，前期曾因混淆"教师排课权限"与"管理员审核权限"，导致教师可以随意修改他人排课，明确角色边界后系统稳定性显著提升：

管理员端（系统管控核心）

用户与权限管理：维护教师与学生账号（审核注册信息、重置密码、逻辑删除无效账号），支持按学号/工号、姓名、班级进行精准筛选；
课程与排课管理：管理课程库（审核课程编号唯一性、设置学分学时），审核教师提交的排课申请（检测时间冲突、教室占用），设置学期选课开放时间；
选课规则配置：设置选课限制（单学期最大选课门数、学分上限），管理选课时间段（分年级分批次开放），处理选课冲突与异常申请；
数据监控与统计：查看选课统计数据（按课程/班级/教师分类），监控系统公告发布，审核异常选课记录。

教师端（教学管理核心）

课程信息维护：维护所授课程的基本信息（课程大纲、考核方式、参考资料），更新课程容量与先修要求；
排课申请管理：提交排课申请（选择上课时间、地点、周次），查看排课审核状态，调整已通过的排课安排；
成绩录入与分析：录入学生成绩（支持批量导入），查看成绩分布统计，下载成绩单模板；
学生管理：查看选修本课程的学生名单，导出考勤与成绩数据。

学生端（微信小程序用户）

课程查询与选课：浏览课程库（按学期、类型、教师筛选），查看课程详情与选课限制，在开放时间段内进行选课/退课操作；
个人课表管理：查看实时个人课表（自动检测时间冲突），跟踪选课状态（待审核、已选中、已满员）；
成绩与进度查询：查看历史成绩单（按学期分类），统计已获学分与GPA，查看毕业要求完成进度；
通知接收：接收选课开放通知、选课结果通知、成绩发布通知等系统消息。

2. 需求分析避坑要点（实战经验总结）

从真实校园场景出发：我们邀请了5名同学模拟"选课高峰期抢课"场景，发现"选课容量实时更新"和"排队机制"是关键痛点。因此，我们设计了基于Redis缓存的实时容量计数和选课队列机制，实用性远高于冗余的"课程社交模块"；
绘制核心业务流程图：使用ProcessOn绘制"选课流程图"、"排课审核流程图"、"成绩录入流程图"，在开题答辩时直观呈现业务逻辑，避免纯文字描述导致的理解偏差；
撰写规范需求文档：明确约束条件，如"单学期选课上限6门"、"总学分不超过25分"、"选课开放时间分年级错峰"、"成绩录入截止时间为考试后2周"等，为后续编码提供明确依据。

3. 可行性分析：三维度论证提升专业性

技术可行性：Spring Boot + MySQL + 微信小程序是成熟的技术组合，学习资料丰富。需要注意的是，选课系统并发要求较高，我们曾使用纯MySQL处理选课请求，在模拟200人同时选课时出现严重延迟，后续引入Redis缓存课程容量信息后性能大幅提升；
经济可行性：开发工具均为免费/开源版本（IDEA社区版、微信开发者工具、MySQL社区版），开发成本为零；系统上线后可极大提高选课效率，减少教务处人工工作量，具备实际应用价值；
操作可行性：小程序端交互遵循微信用户习惯，学生无需额外学习成本；管理后台采用经典的左右布局，教师和管理员易于上手。经测试，学生在2分钟内即可完成选课操作。

二、技术选型：优先稳定适配，拒绝盲目追新

前期曾跟风选用Spring Cloud微服务架构，但因架构复杂、部署困难，导致开发进度严重滞后。后续调整为"Spring Boot 2.7 + MySQL 8.0 + Redis 6.0 + 微信小程序 + Vue 2 + ElementUI"组合，兼顾稳定性、性能与开发效率：

1. 核心技术栈选型说明（含避坑提醒）

技术组件	选型理由	避坑提醒
Spring Boot 2.7.x	快速构建RESTful API，内嵌Tomcat，简化配置，非常适合选课系统这类业务逻辑明确的管理系统	使用`spring-boot-starter-data-redis`集成Redis，避免手动配置连接池；选课高峰期需合理设置连接超时时间
MySQL 8.0 + Redis 6.0	MySQL保证事务一致性（选课、成绩等关键操作），Redis缓存课程容量、选课队列等高并发数据	选课容量必须使用Redis原子操作，我们曾用MySQL行锁，在500并发下出现死锁，切换Redis后QPS提升至2000+
微信小程序	无需安装，即用即走，天然适合校园场景；可方便集成微信登录、消息模板推送	小程序`wx.request`有并发限制，选课按钮需做防重复点击处理；模板消息需申请特定类目
MyBatis-Plus 3.5.x	简化单表CRUD，内置分页插件，极大提高"课程管理"、"学生管理"等数据操作效率	复杂联表查询（如多表关联统计）建议使用原生XML配置，避免LambdaQueryWrapper性能问题
JWT + Spring Security	实现安全的权限控制，管理员、教师、学生三级权限分离，Token机制适合小程序无状态请求	Token过期时间建议设置为2小时，小程序端需实现自动刷新Token逻辑

2. 开发环境搭建步骤（实操指南）

后端环境配置：
- 安装JDK 1.8，配置JAVA_HOME环境变量；
- 使用IDEA创建Spring Boot项目，选择2.7.x版本，依赖勾选Web、MySQL、Redis、MyBatis-Plus；
- 在application.yml中配置数据库连接、Redis连接、JWT密钥、文件上传路径等。
数据库环境配置：
- 安装MySQL 8.0，创建数据库course_selection_db，字符集设置为utf8mb4；
- 安装Redis 6.0，配置持久化策略（RDB+AOF），设置内存大小限制。
微信小程序配置：
- 注册微信小程序账号，获取AppID；
- 在微信开发者工具中创建项目，配置app.js中的API基地址；
- 在project.config.json中配置合法域名（后端API地址）。

三、数据库设计：理清选课核心业务逻辑，避免数据混乱

数据库是选课系统的核心骨架，前期因未设计"选课限制表"，无法实现"分批次选课"和"学分上限控制"。后续采用"实体-状态-约束"分析法梳理表结构，显著提升开发效率。

1. 核心实体与表结构设计（共12张核心表）

学生表 (student)：id, student_no(学号,唯一), name, password(MD5加密), class_id, total_credits(已获总学分), max_credits_per_semester(学期学分上限), status(0-正常/1-停用)等。
教师表 (teacher)：id, teacher_no(工号,唯一), name, title(职称), department_id, contact等。
课程表 (course)：id, course_no(课程编号,唯一), name, credit(学分), hours(学时), capacity(容量), selected_count(已选人数, Redis缓存), type(必修/选修), pre_course_id(先修课程)等。
排课表 (schedule)：id, course_id, teacher_id, semester(学期), week_day(周几), start_section(开始节次), end_section(结束节次), week_range(周次范围,如1-16), classroom, status(0-待审核/1-已通过/2-已取消)等。

关键设计：week_range使用JSON存储如[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16]，方便计算冲突。
选课表 (selection)：id, student_id, course_id, schedule_id, selection_time, status(0-待处理/1-已选中/2-已退选/3-冲突待解决)等。
选课限制表 (selection_limit)：id, semester, grade(年级), max_courses(最大选课门数), max_credits(最大学分), start_time(选课开始时间), end_time(选课结束时间), batch(批次)等。
成绩表 (grade)：id, student_id, course_id, regular_score(平时成绩), exam_score(考试成绩), total_score(总评), grade_point(绩点), semester等。
冲突检测记录表 (conflict_log)：id, student_id, conflict_type(时间冲突/学分超限/容量已满), conflict_detail, resolve_status等。

关键避坑提醒：

课程容量必须原子操作：选课时先Redis.decr(course_capacity_key)，成功后再写MySQL，防止超选。
时间冲突检测算法：将学生已选课程的时间段转换为时间区间集合，新选课程与之比对，使用线段树或区间合并算法优化性能。
选课队列机制：热门课程使用Redis List实现排队，避免瞬间高并发打垮数据库。

2. 表关联测试SQL示例

-- 查询学生"张三"2023年秋季学期的选课情况及成绩
SELECT 
    s.name AS student_name,
    c.course_no, c.name AS course_name, c.credit,
    sch.week_day, sch.start_section, sch.end_section, sch.classroom,
    g.total_score, g.grade_point
FROM selection sel
JOIN student s ON sel.student_id = s.id
JOIN course c ON sel.course_id = c.id
JOIN schedule sch ON sel.schedule_id = sch.id
LEFT JOIN grade g ON sel.student_id = g.student_id AND sel.course_id = g.course_id
WHERE s.name = '张三' 
  AND sch.semester = '2023秋'
  AND sel.status = 1  -- 已选中
ORDER BY sch.week_day, sch.start_section;

-- 统计教师"李老师"所授课程的平均分与选课人数
SELECT 
    t.name AS teacher_name,
    c.name AS course_name,
    COUNT(DISTINCT sel.student_id) AS student_count,
    AVG(g.total_score) AS avg_score
FROM teacher t
JOIN schedule sch ON t.id = sch.teacher_id
JOIN course c ON sch.course_id = c.id
LEFT JOIN selection sel ON sch.id = sel.schedule_id AND sel.status = 1
LEFT JOIN grade g ON sel.course_id = g.course_id AND sel.student_id = g.student_id
WHERE t.name = '李老师'
GROUP BY c.id;

四、功能实现：聚焦选课核心流程，打造答辩亮点

无需开发所有功能，优先完成3个核心模块即可满足答辩要求，且能突出开发重点：

1. 核心模块一：学生选课与冲突检测（用户侧亮点）

这是系统价值的直接体现，必须保证高并发下的正确性。

选课流程：学生进入小程序 -> 查看可选课程列表（自动过滤时间冲突、先修课程未修、容量已满的课程）-> 点击选课 -> 系统实时检测冲突 -> 成功则扣减容量 -> 返回成功结果。
关键技术实现：
- Redis原子操作保证容量：Long remaining = redisTemplate.opsForValue().decrement(courseKey); if (remaining >= 0) { // 选课成功 } else { // 容量不足，回滚 }
- 时间冲突检测：将week_day + section_range + week_range编码为唯一时间块，使用BitMap存储学生已选时间块，新选课程时间块与之按位与，结果不为0则冲突。
- 选课队列：对热门课程使用redisTemplate.opsForList().leftPush(queueKey, studentId)实现排队。
页面设计：小程序课程列表页显示实时剩余容量，选课按钮有防重复点击倒计时；个人课表页用不同颜色区分已选/可选/冲突课程。

2. 核心模块二：教师排课与成绩管理（管理侧核心）

此模块体现了系统的管理能力和业务流程完整性。

排课流程：教师提交排课申请（选择课程、时间、地点）-> 系统自动检测教室占用、教师时间冲突 -> 管理员后台审核 -> 审核通过后课程开放选课。
成绩录入：教师进入成绩管理页 -> 选择课程 -> 下载成绩模板或在线录入 -> 系统自动计算总评和绩点 -> 提交后学生端即时可见。
关键实现：排课冲突检测使用教室+时间段的联合唯一索引；成绩录入支持Excel批量导入，使用EasyExcel解析，避免内存溢出。

3. 核心模块三：管理员选课规则配置（系统管控核心）

核心功能是灵活配置选课规则，体现系统的可配置性和健壮性。

配置流程：管理员设置学期选课时间（分年级、分批次）、学分上限、选课门数上限、特殊课程选课条件（如仅限某专业）。
实时监控：后台仪表盘实时显示选课数据（总选课人次、热门课程排行、冲突统计），支持手动调整课程容量、处理异常选课记录。

五、系统测试：全面排查高并发场景，保障答辩顺利

选课系统的特殊性在于高并发和一致性要求。我们曾因未充分测试"秒杀式选课"场景，在答辩演示时出现"超卖"现象（课程容量100，选出了105人）。必须针对性完成以下测试：

1. 核心功能测试用例

测试场景	操作步骤	预期结果	测试重点
高并发选课	使用JMeter模拟500用户同时选同一门课（容量100）	仅有100人成功，其余返回"容量已满"，数据库与Redis数据一致	Redis原子性、数据库事务隔离级别
时间冲突检测	学生已选周一1-2节课程A，再选周一1-2节课程B	系统提示"时间冲突"，禁止选课	冲突检测算法正确性、边界条件
学分上限控制	学生已选20学分，系统上限25学分，再选6学分课程	系统提示"学分超限"，禁止选课	选课限制实时生效
选课队列测试	容量1，100人排队选课	第一人成功，其余进入队列，有人退课后队列顺序递补	Redis List操作、队列公平性

2. 性能压力测试指标

单机QPS：选课接口 ≥ 500，查询接口 ≥ 1000；
响应时间：选课操作 ≤ 200ms，课表查询 ≤ 100ms；
并发用户：支持 ≥ 1000用户同时在线选课；
数据一致性：0超卖，0错误选课记录。

3. 测试报告撰写要点

问题总结：明确记录已修复的高并发问题，如"Redis与MySQL数据不一致通过分布式锁解决"、"时间冲突检测性能瓶颈通过BitMap优化"；
测试结论：总结核心功能与性能指标，如"系统在高并发下数据一致性达标，核心业务流程无严重BUG，满足校园选课场景需求"。

六、答辩准备：突出解决的高并发问题，展现技术深度

演示脚本化：准备5分钟演示流程：管理员后台配置选课规则 -> 学生小程序抢课演示（展示防超卖） -> 教师后台录入成绩 -> 后台数据统计展示。重点演示"高并发选课不超卖"的亮点。
突出问题解决能力：答辩时重点讲解选课系统的技术难点：
- "如何防止课程超选？"：展示Redis原子操作+数据库事务的代码片段，解释CAP理论中的权衡。
- "如何检测时间冲突？"：展示时间块编码与BitMap检测算法，对比暴力查询的性能提升数据。
- "如何应对选课高峰？"：介绍Redis缓存、队列、限流降级的三层保护策略。
预设问答准备：
- Q：如果Redis宕机怎么办？ A：我们有Redis持久化+RDB备份，同时MySQL有容量字段作为兜底，重启后从MySQL同步数据到Redis。
- Q：系统如何保证公平性？ A：对于热门课程，我们采用"排队+随机递补"机制，避免纯先到先得导致的网络优势不平等。
- Q：成绩安全性如何保障？ A：成绩修改需要双重审核（教师提交+教研室主任审核），且有完整的操作日志。

结语

开发一个"大学生选修选课系统"，真正的挑战不在于CRUD，而在于高并发下的数据一致性和复杂的业务规则校验。聚焦"选、排、管"核心闭环，把容量控制、冲突检测、权限管理做扎实，你的毕设就成功了一大半。

如果需要本系统的完整数据库建表SQL脚本（带压力测试数据）、Spring Boot后端核心代码模块（含高并发选课解决方案）、微信小程序页面布局示例，可以在评论区留言"选课系统"获取参考。

收藏本文，选课系统开发不迷路！祝各位同学毕业设计顺利，轻松通过答辩！🎓