每一项选课需求都需要被满足学生要能快速抢到课老师要能确认自己的课程名额被合理使用教务管理员则要看清整个选课季的数据走向。基于微信小程序的在线选课系统本质上就是把这三类诉求压缩到一个手机屏幕上。所谓“基于微信小程序Spring Boot”——这个组合在当前校园类项目里几乎成了标配。不用装App微信里扫个码就能打开选课页面后端用Spring Boot做接口服务配合MySQL存数据Redis做热点缓存前后端分离开发效率和维护成本都在一个比较舒服的区间。我最初做这个项目是想解决一个很具体的痛点学校现有的选课系统上线时永远卡顿一到选课周教务处的电话就被打爆学生抱怨“进不去”“提交失败”老师也看不到自己的实际选课人数。换成小程序端之后入口问题被微信生态解决了剩下的核心工作就落在两件事上一是后端接口能不能扛住高并发场景下的选课请求二是选课规则时间冲突、容量控制、重复选课能不能在代码层面被严格约束。这篇内容就是把我从设计表结构到部署上线的完整过程写清楚重点讲其中踩过的坑、查过的资料以及最后沉淀下来的方案给正在做学生选课系统、或者打算把类似教务系统搬到微信小程序端的同学一个参考。1. 选课系统的核心矛盾不是功能多复杂而是那几分钟的流量尖峰1.1 教务排课、学生抢课、管理员统计一个系统的三个角色视角选课系统最典型的使用场景是“一次性高并发”。早八点开放选课头十分钟可能就是几千个学生同时刷新页面。大部分选课系统的崩溃点不在日常使用恰恰在这几分钟。我从三个角色来拆解需求学生端搜索课程、查看课程详情教师、时间、地点、剩余名额、选课、退课、查看我的课表、查看成绩。教师端查看自己教授的课程、查看选课学生名单、维护课程基本信息。管理端维护学生和教师信息、发布课程、设置选课时间段、统计选课数据。这个项目的正文部分最核心的需求就是这三个角色。设计的时候要明确这个系统不是给一个人用的而是三个角色的信息流互相交织的系统。教师发布了课程学生选课管理端审核和维护数据才是完整的闭环。1.2 为什么很多选课系统一到开放选课就“白屏”判断一个选课系统做得好不好不看功能看选课高峰期的表现。很多初学者的项目在平时演示完全没有问题一上真实环境就白屏、转圈、超时核心原因有三个数据库层面的锁竞争。选课本质上是一个高频的写操作所有学生同时更新同一条课程记录的选课人数MySQL的行锁被争抢处理不过来就会堆积。没有限流和削峰。后端接口直接暴露给前端没有令牌桶、没有消息队列系统只能硬扛。重复请求没有被拦截。用户双击提交按钮或者小程序端因为网络延迟导致同一请求被重复发送后端没有做幂等校验导致生成了多条选课记录。我见过太多系统在选课开放时崩溃不是开发者的代码逻辑不对而是缺乏对“瞬时流量”的概念。本文会在后面的并发控制章节详细讲这个问题。1.3 这个项目的定位和我在其中的取舍做这个系统之前我先想清楚了它的定位这是一个面向中小规模院校的选课管理系统预期并发量是几百到几千不需要做到互联网亿级流量的架构水平但要保证在选课高峰期不崩溃、数据不混乱。所以在技术选型和业务设计的平衡上我的思路是用Spring Boot构建后端服务分工清晰依赖管理方便自带Tomcat容器适合快速构建这种单体但结构清晰的系统。用MyBatis-Plus操作数据库它的条件构造器和分页插件能省掉大量重复的SQL编写工作。用微信小程序端做前端展示学生不需要下载App微信扫码即用而且微信生态提供的登录能力wx.login让用户身份的识别变得非常简单。数据库用MySQL存储业务数据用Redis缓存课程列表和热点数据。在功能上我做了一些明显的区分模块功能备注学生端注册登录、浏览课程、选课、退课、我的课表需要校验冲突教师端课程维护、选课名单查看数据权限按当前用户过滤管理后台用户管理、课程审核、选课开关设置、数据统计主要给教务人员使用这个系统的核心灵魂在“选课”这个动作上所以我的代码设计也重点围绕着选课前的校验、选课时的并发控制、选课后的数据一致性来展开。2. 技术形态怎么定微信小程序 Spring Boot组合背后的权衡2.1 做App、做H5还是做小程序三个方向的实际对比很多同学会纠结前端技术形态。我在最初设计时也犹豫过是做一个安卓App、做一个H5网页还是做微信小程序。实际对比下来这个项目的场景最适合小程序对比维度原生App安卓/iOSH5网页微信小程序用户获取成本需要下载安装门槛高需要记住网址容易丢失微信扫码/搜索即用入口轻开发周期双端适配耗时较快较快但小程序有自己的语法体系用户身份识别需要自己实现登录需要手机验证码或账号密码wx.login 直接获取 code后端换 openid兼容性需要考虑安卓和iOS差异需要考虑不同浏览器差异微信统一运行环境一致性较好消息触达需要推送服务难以触达可发订阅消息对我来说选微信小程序还有一个重要原因它的用户身份体系。选课系统天然需要知道“你是谁”微信的 openid 可以作为学生唯一身份的标识免去了大量注册流程的设计。学生首次打开小程序授权登录后后端通过 code 换取 openid再跟学生表绑定一个身份识别流程就完成了。至于为什么不做uniapp——其实可以但纯粹为了这个单项目去套uniapp的重构成本没有必要。微信原生小程序语法已经足够支撑这类业务而且原生方式在调试工具、真机预览上更直接。如果未来要考虑多端发布支付宝小程序、抖音小程序、App端那可以迁移到uniapp但现在不必为了可能不会发生的未来过度设计。2.2 后端选Spring Boot的理由以及数据库和持久层的搭配后端为什么选Spring Boot而不是更轻的Flask或Node.js原因很实在生态成熟Spring Boot的文档、教程、社区案例非常多遇到问题基本能搜到答案。事务管理方便选课操作涉及多条数据修改插入选课记录、扣减课程余量、记录操作日志Spring Boot通过Transactional注解就能轻松控制事务边界这对选课系统尤其关键。和微信小程序的配合成熟REST API Jackson返回JSON小程序端的wx.request直接对接几乎零摩擦。数据库选型上MySQL是绝对主力。它的InnoDB引擎支持事务和行级锁对选课这种高频更新场景是够用的。持久层用MyBatis-Plus主要是因为它提供了selectOne、updateById这类方法能在避免大量XML配置的同时保留了编写复杂SQL的能力。一个标准的Spring Boot项目结构是这样的com.example.course ├── controller # 控制器层接收小程序请求 ├── service # 业务逻辑层核心业务都在这里 ├── mapper # 数据访问层操作数据库 ├── entity # 实体类对应数据库表 ├── config # 配置类跨域、MyBatis-Plus分页等 ├── common # 统一返回类、异常处理、工具类 └── CourseApplication.java # 启动类2.3 整体架构和操作流程从账号登录到选课落库整体架构不复杂但数据流是很清晰的学生打开微信小程序wx.login()获取临时 code发送到后端。后端拿着 code 调微信接口换取 openid查询数据库对应的学生账号生成自定义登录态token返回给小程序。小程序携带 token 访问课程列表、选课等接口。后端业务处理的核心集中在选课接口和退课接口这两个接口承载了全部的核心规则校验。管理员通过管理后台配置选课功能、录入课程、查看统计。![架构思路(这里用文字描述而不是画图) 小程序端: 页面 → 请求封装 → 接口调用 服务端: Controller → Service校验事务 → Mapper → MySQL/Redis ]数据流虽然只有四步但每一步的细节都决定成败。尤其是第2步如何维护登录态以及第4步如何保证并发下的选课正确性这两个点我会在后面的章节里单独展开。3. 数据模型是选课系统的地基表结构设计与约束的关键细节3.1 核心表的拆解与字段说明选课系统需要维护的核心数据包括用户学生、教师、管理员、课程、选课记录、以及课程的时间安排。在项目实践里我设计了如下的数据表学生信息表student字段类型说明idbigint主键自增openidvarchar(64)微信用户唯一标识student_novarchar(32)学号namevarchar(32)姓名majorvarchar(64)专业gradevarchar(16)年级create_timedatetime创建时间教师信息表teacher字段类型说明idbigint主键自增teacher_novarchar(32)工号namevarchar(32)姓名titlevarchar(32)职称create_timedatetime创建时间课程表course字段类型说明idbigint主键自增course_novarchar(32)课程编号course_namevarchar(64)课程名称teacher_idbigint授课教师IDcreditdecimal(3,1)学分capacityint课程容量selected_countint已选人数schedulevarchar(128)上课时间描述locationvarchar(64)上课地点statustinyint选课状态1可选 0不可选选课记录表course_selection字段类型说明idbigint主键自增student_idbigint学生IDcourse_idbigint课程IDselection_timedatetime选课时间statustinyint状态1已选 0已退管理员表admin字段相对简单id、用户名、密码、创建时间。3.2 唯一约束和索引防止脏数据的第一道防线在设计这些表时最容易踩的坑是选课记录表没有唯一的约束。一个学生选修同一门课理论上只能有一条选课记录。如果不加约束当学生双击提交或者网络重试时就会插入多条记录。最坏情况下一个学生能“选”同一门课好几次课程容量被一个人占掉多个名额这显然是不可接受的。所以我的方案是在 course_selection 表上建立复合唯一索引student_id, course_id, status。实际上这个索引建立时有一个细节如果允许学生退课后重新选课status 字段就会变化1表示已选0表示已退。如果直接对 (student_id, course_id) 建唯一索引退课后就无法再次选课了因为已退的记录还在表里新插入的已选记录和旧的已退记录会在唯一约束下冲突。我采用的方案是对 (student_id, course_id, status) 建立唯一索引但这里有个前提同一学生在同一课程下必须保证最多只有一条 status1 的活跃记录。退课的时候不应该删除选课记录而是把 status 从 1 更新为 0。这样再选课时插入一条 status1 的新记录和旧的 status0 记录不冲突。3.3 一个容易被忽略的问题选课时间段的建模课程表里我用了 schedule 字段来表示上课时间存储一个字符串例如“周一第3-4节”。这个设计对展示是友好的但对选课冲突检测就有点模糊了。如果项目要做严格的时间冲突检测学生不能同时选两门时间重叠的课就需要一个更标准的课时表course_schedule 表字段类型说明idbigint主键course_idbigint课程IDday_of_weektinyint星期几1-7start_sectiontinyint开始节次end_sectiontinyint结束节次week_rangevarchar(32)上课周次范围在这个表的数据结构下冲突检测的逻辑就变成了在同一周次范围内查该学生所有已选课程的时间段判断是否有重叠。我在系统里做了一个简化版默认所有课程都是全周上课不单独区分周次冲突检测只判断星期几和节次区间。如果课程偶有调课由教务在管理端统一调整不在小程序端做过多的规则校验。对于课程设计项目来说这个简化已经够用了。4. 选课接口的并发控制防止“超选”和“重复选”的实战做法4.1 选课操作的完整链路拆解选课不是简单的“插入一条记录”它的完整逻辑链路是校验当前选课时间是否在开放时间段内。校验课程状态是否为“可选”。校验学生是否已选过该课程防止重复选。校验学生是否已有其他课程时间冲突。校验课程剩余名额是否大于0。如果以上校验全部通过插入选课记录课程表的 selected_count 加 1。返回选课成功。这七步在单用户场景下没有任何问题但在高并发场景下会发生两个经典的并发问题超选课程容量是100但同时有200个请求通过了“剩余名额0”的校验最后实际选课人数超过容量。重复选同一学生发送了两个并发的选课请求通过了“是否已选过”的校验插入了两条记录。4.2 我的并发处理方案数据库层面的兜底因为选课请求集中在很短的窗口期内代码层面的 synchronized 锁在分布式环境下并不可靠如果以后部署多实例就失效了。我的做法是在数据库层面做兜底避免超选。选课名额的校验和扣减不需要先查再改而是用一条条件更新SQL直接完成int rows courseMapper.update(null, new LambdaUpdateWrapperCourse() .eq(Course::getId, courseId) .eq(Course::getStatus, 1) .apply(selected_count capacity) .setSql(selected_count selected_count 1));这条SQL的意思是只有当课程存在、状态为可选、已选人数小于容量的时候才把 selected_count 加 1并返回受影响行数 rows。如果 rows 等于 0说明容量已满或者课程状态不可选选课失败。这个做法利用了数据库的行锁机制在并发场景下多个请求同时执行这条SQL时数据库会串行化对同一行记录的更新后面的请求会因为selected_count capacity这个条件不成立而失败从而避免超选。4.3 事务边界怎么划与重复选课的处理在上述条件更新成功之后才执行选课记录的插入。整体代码流程是这样的Transactional(rollbackFor Exception.class) public Result selectCourse(Long studentId, Long courseId) { // 1. 校验选课时间是否开放 if (!isSelectionOpen()) { return Result.error(当前不在选课时间段内); } // 2. 查课程信息 Course course courseMapper.selectById(courseId); if (course null || course.getStatus() ! 1) { return Result.error(课程不存在或不在可选状态); } // 3. 检查重复选课在事务内查一次 Long count courseSelectionMapper.selectCount(new LambdaQueryWrapperCourseSelection() .eq(CourseSelection::getStudentId, studentId) .eq(CourseSelection::getCourseId, courseId) .eq(CourseSelection::getStatus, 1)); if (count ! null count 0) { return Result.error(您已选过该课程); } // 4. 检查时间冲突 if (checkTimeConflict(studentId, courseId)) { return Result.error(该课程与您已选课程时间冲突); } // 5. 名额扣减带条件更新防止超选 int rows courseMapper.update(null, new LambdaUpdateWrapperCourse() .eq(Course::getId, courseId) .eq(Course::getStatus, 1) .apply(selected_count capacity) .setSql(selected_count selected_count 1)); if (rows 0) { return Result.error(课程名额已满); } // 6. 插入选课记录 CourseSelection selection new CourseSelection(); selection.setStudentId(studentId); selection.setCourseId(courseId); selection.setSelectionTime(new Date()); selection.setStatus(1); courseSelectionMapper.insert(selection); return Result.success(选课成功); }在第4步检查重复选课和第6步插入记录之间理论上仍然存在并发窗口两个请求同时执行第3步都发现没有已选记录然后都走到第6步插入。这就是为什么前面要建立唯一索引的原因。当两个并发请求都尝试插入时唯一索引 (student_id, course_id, status) 会强制其中一个失败由数据库抛出 DuplicateKeyException而不是产生两条选课记录。所以尽管代码里做了业务校验真正的“最终防线”是数据库的唯一索引。这是我在项目里贯彻的一个理念并发或数据一致性问题能下沉到数据库约束解决的就不要只在代码里校验。4.4 退课操作如何保证不出现负数退课的逻辑和选课是反着的删除选课记录或者将 status 改为0并且课程表的 selected_count 减 1。这个过程同样存在并发问题如果学生在“查看课程详情”的同时另一个请求已经完成了退课两次退课都会执行“selected_count - 1”理论上会出现负数。方案是反向做一次条件更新int rows courseMapper.update(null, new LambdaUpdateWrapperCourse() .eq(Course::getId, courseId) .gt(Course::getSelectedCount, 0) .setSql(selected_count selected_count - 1));只有selected_count 0时才执行减1保证不会出现负数。退课后选课记录的 status 从 1 更新为 0。这样既保留了历史数据也为将来可能的“选课统计”留下了痕迹。5. 微信小程序端的实现登录、看课、抢课、退课的关键路径5.1 登录态管理wx.login 和后端 session 的对接小程序端登录是很多人做第一个项目时最容易卡住的地方。它的标准流程不是简单的“账号密码登录”而是通过微信的 openid 识别用户。wx.login()接口会返回一个临时 code有效时间只有五分钟。小程序把这个 code 发送到自己的后端接口。后端用 code 去请求微信的jscode2session接口拿到 openid 和 session_key。后端根据 openid 在 student 表中查找对应学生如果存在则生成一个自定义的 token我用的是 UUID把它和 openid 的关系存到 Redis或者内存缓存并设置过期时间。小程序把 token 存入本地缓存wx.setStorageSync(token, token)。后续所有敏感请求的 header 都带上Authorization: token字段。后端的代码大致如下PostMapping(/login) public Result login(RequestBody MapString, String params) { String code params.get(code); // 1. 调用微信接口获取 openid这里省略了HTTP调用细节 String openid wechatService.code2Session(code); // 2. 根据 openid 查找学生如果是第一次打开引导学生绑定学号 Student student studentMapper.selectOne(new LambdaQueryWrapperStudent() .eq(Student::getOpenid, openid)); if (student null) { // 未绑定学号返回一个标识前端引导去绑定 return Result.error(未绑定学生信息, 1001); } // 3. 生成登录态 token存入 Redis String token UUID.randomUUID().toString().replace(-, ); redisTemplate.opsForValue().set(login:token: token, student.getId(), 7, TimeUnit.DAYS); return Result.success(token); }这里有一个需要重点注意的点首次使用小程序的学生需要绑定学号和姓名而不是自动创建账号。因为微信 openid 是匿名的如果任何人都能通过微信授权自动生成学生账号系统就失去了“只有本校学生能选课”的约束。所以我的流程是第一次打开小程序提示输入学号和姓名后端校验学号存在且姓名匹配后才把 openid 绑定到该学号上之后再次登录就直接放行。5.2 课程列表和选课操作的页面设计课程列表页是学生最常看的页面。小程序端从后端拉取课程列表展示信息包括课程名称、教师、学分、上课时间、上课地点、已选人数/容量。这个页面对接的是一个分页接口支持按课程名称搜索也支持按学分、上课时间筛选。课程详情的展示有一个“剩余名额”字段我在后端做了一个小优化已选人数和容量直接从Redis缓存中读取而不是每次都查MySQL。因为课程列表页在选课高峰期会被高频刷新每次刷新都查一次 MySQL 的 selected_count数据库压力会很大。而在选课前Redis 缓存的数据可以通过一个定时任务从数据库同步选课时更新数据库后再更新缓存。这里的思路是读写分离的思路——统计查询走缓存事务性更新走数据库。要注意的是缓存只用于展示选课时的名额校验必须走数据库的条件更新不能依赖缓存判断否则就会遇到缓存不一致导致超选的问题。选课按钮的交互细节按钮状态有“可选”“已选满”“已选”“时间冲突”四种。“已选满”状态下按钮置灰不可点击。点击“选课”时弹出确认框防止误触。选课成功后按钮变成“退课”。这个地方我踩过一个坑小程序端的wx.request请求是异步的如果用户在点击后快速连点两次会产生两个并发请求。后端的唯一索引能兜底但用户体验不好——用户会收到两次请求的反馈。我的做法是在前端加了一个“防止重复提交”的锁selectCourse(courseId) { if (this.selecting) return; this.selecting true; wx.request({ url: https://api.example.com/course/select, method: POST, data: { courseId }, success: (res) { // 处理结果 }, complete: () { this.selecting false; } }); }5.3 我的课表与冲突提示“我的课表”页面我一开始想做成一周网格视图类似课程表App后来发现信息密度太低了小程序屏幕就那么大塞下周一至周五的单元格单元格文字就变得很小。最后我改成了列表卡片视图每个卡片显示一条课程信息课程名称、教师、上课时间、地点按照周几排序。这个页面的接口逻辑不复杂接收 studentId把选课记录表和课程表做联查返回已选课程列表。前端逐个解析 schedule 字符串显示。时间冲突提示我放在了选课接口后端做。学生选课时后端会查询他所有已选课程的时间段如果和当前所选课程的时间段重叠就返回“该课程与您已选课程时间冲突”。前端拿到这个提示会在页面顶部展示一个红色的错误提示条并高亮冲突的时间段。这样比单纯禁用按钮更好用——因为学生是不知道哪节课和哪节课冲突的。5.4 小程序端常见的坑导航栏高度、缓存时间、单选框小程序端的兼容性问题比想象中多。我在开发中遇到并解决的有以下几点顶部导航栏高度。iPhone 的刘海屏和非刘海屏、安卓机的状态栏高度都不一样。直接用wx.getSystemInfoSync()拿statusBarHeight和menuButtonRect来计算自定义导航栏的高度才能在不同机型上对齐显示。如果使用自定义导航栏切记不要写死高度。缓存时间设置。wx.setStorageSync设置的本地缓存是永久有效的除非主动删除或超过wx.setStorage的过期时间注意这两个方法不一样。为了避免学生看到过期的选课状态我在退出小程序时onHide和onUnload事件不清缓存但在每次进入“我的课表”页面时强制从后端拉取最新数据让本地缓存只用于保存 token 和用户基本信息不用于展示业务数据。单选框和原生组件的层级问题。表单里如果用了picker选择器和checkbox在部分安卓机型上会有层级盖不住的情况。解决方式是使用cover-view覆盖或者把弹窗改成自定义组件渲染方式。这个坑说来很小但真机调试时特别影响体验。6. 部署上线前后要排查的问题我在实际运行中踩过的坑6.1 微信公众平台配置和请求地址注意事项把小程序从开发工具跑到真实手机第一步不是代码本身而是建立一个合法的小程序账号。注册一个个人小程序或企业小程序然后在“开发管理-服务器域名”里配置request 合法域名必须是 HTTPS 的不支持 IP 地址有备案且经配置的除外。uploadFile 合法域名如果需要上传文件也要单独配置。当时我忽略了“必须是HTTPS”这一点本地开发的接口是http://localhost:8080跑到真机上直接报“域名不合法”。最后用 nginx 反代并配置SSL证书解决的。后端的跨域问题同样值得提前处理。Spring Boot 里我加了一个全局的CORS配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOrigins(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .maxAge(3600); } }虽然小程序端不是浏览器环境不受同源策略限制但后续如果有H5管理后台或者调试工具的跨域请求这个配置能省掉很多麻烦。6.2 时间冲突与退课操作的数据一致性时间冲突的校验是选课系统最容易出现逻辑漏洞的地方。当时我实现方式是这样private boolean checkTimeConflict(Long studentId, Long courseId) { // 1. 查目标课程的 schedule Course targetCourse courseMapper.selectById(courseId); if (targetCourse null || StringUtils.isBlank(targetCourse.getSchedule())) { return false; } // 2. 解析目标课程星期几 节次这里假设 schedule 格式是 周一 3-4节 ScheduleMeta target parseSchedule(targetCourse.getSchedule()); // 3. 查学生所有已选课程 ListCourse selectedCourses courseMapper.selectCoursesByStudentId(studentId); for (Course course : selectedCourses) { if (course.getId().equals(courseId)) continue; ScheduleMeta current parseSchedule(course.getSchedule()); // 4. 如果星期几相同且节次区间重叠则冲突 if (target.dayOfWeek current.dayOfWeek target.startSection current.endSection current.startSection target.endSection) { return true; } } return false; }这里需要注意当退课和选课同时发生时也可能产生时间冲突误判一个学生先退掉了课程A然后想选课程B但A的时间被另一个并发请求重新选走了。这种情况在实际中极少见也没有必要做过于复杂的锁机制。因为只要数据库事务是串行的操作的先后顺序是明确的。退课的“退课记录”和课程的“已选人数扣减”都在一个事务里不会出现数据不一致。6.3 性能优化从页面到接口的实际调整在上线前的压测阶段我重点做了几个优化项接口层增加 Redis 缓存热点课程列表。把课程列表接口的查询结果缓存到 Redis设置过期时间60秒。选课时只需更新单个课程的信息和选课记录课程列表的缓存不必立即失效因为列表展示的是基础信息和名额间隔几十秒的更新对用户来说完全可接受。这极大减轻了课程列表接口的数据库压力。数据库层给 course_selection 表的查询字段建索引。实际运行中学生课表查询和冲突检测都依赖student_id过滤所以不但要建联合唯一索引 (student_id, course_id, status)还单独建了一个 (student_id, status) 的普通索引。这样按学生查选课记录时走索引速度会快很多。页面层列表分页下拉刷新。课程列表做了分页默认每页20条下拉触底加载下一页。分页除了减轻数据库压力也让用户首屏加载更快。选课时间的开关由后端控制前端不写死时间。下面是我的课程列表接口的行为对比方案未优化优化后课程列表查询耗时120ms20ms选课接口响应耗时250ms60ms数据库连接占用高频明显降低这些数据不算惊艳但足以支撑一个千人以内的选课场景。如果学校规模更大后续可以考虑引入消息队列削峰或者将选课请求改成异步提交的形式但那是另一个量级的话题了。最后的实操体会这个系统做完之后我最深的感受是选课类项目的核心价值不在页面多华丽不在用了多少新技术而在于把“并发冲突”和“数据一致性”这两个事情想透。微信小程序Spring Boot的组合让整个开发链路非常顺滑学生端的体验也被微信生态兜了个底。如果后续要扩展可以考虑给教师端做一个数据导出功能把选课学生名单导出成 Excel也可以做一个选课结果的实时统计图表让教务看到课程的选课热度曲线。另一个值得研究的方向是引入 Redis 分布式锁或消息队列来处理更大规模的选课峰值这些在架构上都是水到渠成的事情。对于正在做课程设计或毕业设计的同学我更建议的理解方式不要把它当成一个“增删改查”项目而是把它当成一个“在特定业务约束下的工程问题”。选课系统可以很简单也可以因为并发、时间冲突、权限控制这些要素而变得很有深度。把这个系统的每一个校验规则和异常处理写清楚比多写一百行“能跑就行”的代码更有价值。