如果你今年正在为毕业设计选题发愁尤其是计算机专业或者软件工程方向的那我建议你认真看看这篇文章里提到的“Java 微信小程序”这套体育选课系统方案。体育选课系统这个题目本质上是高校教务场景里最典型的“高并发查询 低频事务操作”业务模型拿来练手再好不过。它既不像电商系统那样涉及复杂的支付和库存也不像后台管理系统那样枯燥乏味而是踩在了“小程序前端 Java后端 数据库设计 权限管理”多个技术点的交叉口上。无论你是想快速完成毕设还是想在简历上多一个拿得出手的完整项目这套系统都算得上一个性价比极高的选择。这篇文章就把我当时做这个题目时踩过的坑、想明白的原理、以及最后落地的完整设计思路全部写出来给你一条可以照抄的路线。1. 选题价值分析为什么体育选课系统是毕设的“安全牌”很多人选毕设题目很随意到最后答辩才发现难度不够、创新点不足、工作量虚高。体育选课系统这个题目好就好在它虽然看起来简单但该有的功能模块一个不少而且业务逻辑非常清晰适合用来展示你的工程能力。1.1 业务复杂度刚刚好适合学生独立完成体育选课系统的核心流程不复杂学生登录小程序查看可选的体育课程提交选课申请系统判断名额余量成功后生成选课记录老师可以维护课程信息查看选课名单管理员负责基础数据管理。这套流程覆盖了典型的“用户端 管理端”双层架构前端小程序负责学生操作后端管理平台负责教师和管理员操作。业务逻辑简单但不单薄不会出现毕设做到一半发现自己控制不了复杂度的情况。拿一个具体的模块来举例。课程名额的并发扣减是这类系统的核心难点之一也是面试官最爱问的点。一个学生同时打开了五个课程页面正在犹豫选哪个等他想好提交请求的那一瞬间该课程的名额可能已经被其他同学抢光了。你需要在服务端做严格的名额校验和原子性扣减这涉及的不仅仅是SQL更是对数据库事务隔离级别的理解。如果把这些内容全部掌握并写进论文你的毕设工作量已经非常扎实了。1.2 跨平台场景天然贴合“小程序 后端”主流架构现在高校的教务类服务几乎都在从App和网页端往微信小程序迁移。原因很直接学生不用额外安装App打开微信搜一下或者扫码就能用获客成本趋近于零后台的开发成本也比双端适配低不少。从技术栈的角度来看这种题目让你有机会完整地实践一套前后端分离的开发流程。后端用Java Spring Boot提供RESTful API前端用微信小程序原生框架接收数据并渲染页面二者通过HTTPS JSON进行交互。这套模式和业界的日常工作方式完全一致。说到热搜词里频繁出现的uniapp微信小程序我多说一句。如果你是毕设答辩时间比较紧或者想省掉一部分重复劳动可以考虑用uniapp来开发小程序端它的Vue语法写起来确实比原生WXML更顺手。但如果你希望通过这个项目加深对微信小程序底层机制的理解那我还是建议先用原生框架做一遍踩过原生框架的坑再来抽象。我当时用的就是原生方式答辩时老师问我“小程序的生命周期都有哪些”我可以当场答出onLoad、onShow、onReady、onHide、onUnload各自触发的时机这个细节让老师印象很深。2. 系统整体设计从需求分析到模块划分的完整链路系统设计没有你想象中那么玄乎说白了就是把一个笼统的需求拆成一堆能落地的具体功能点。我当时先从需求分析文档开始写把学生、教师、管理员三类角色的操作梳理清楚再画用例图和数据流图最后才动代码。2.1 角色权限设计三类用户的身份边界怎么划分体育选课系统的用户角色必须分清楚因为不同角色操作的资源差异很大权限模型搞混了会带来严重的数据安全隐患。学生浏览课程、选课、退课、查看个人课表、维护个人资料。教师管理自己负责的课程信息、查看选课学生名单、设置课程名额和上课时间。管理员维护教师账号、维护课程类别、发布选课公告、处理异常选课记录。我从一开始就做了“基于RBAC的简易权限模型”。后端拦截器根据请求头里携带的token去查当前用户的角色然后判断该角色是否有权限访问对应的接口。比如删除一门课程这个操作只允许管理员执行教师只能修改自己创建的课程学生就根本没有访问这个接口的资格。权限这块我建议你不要用硬编码判断。虽然硬编码写法最简单但如果后面要加一个“教务秘书”角色你会发现所有接口的if判断都要改一遍代码很脆。我当时用的是Spring Security JWT的组合方案配置几个过滤器链把不同接口的访问规则写清楚后期的可维护性会高很多。2.2 模块划分与页面流转逻辑整个系统我分成三个主要端小程序端作为学生的主战场包含登录页、首页课程列表、课程详情页、选课确认弹窗、个人中心、我的课表这六个核心页面。后端管理端单独做了一个PC网页技术栈也用的Vue Element UI功能有课程管理、类别管理、学生管理、教师管理、选课统计。后端Java服务则承担了所有业务的处理对小程序和PC端提供统一的接口层用Swagger生成API文档前端联调的时候直接看在线文档就行不需要反复问后端要接口说明。这里有个设计细节值得说就是课程状态。体育课程有“未开始选课”“选课进行中”“选课已结束”“课程已结课”这四种状态。选课接口必须校验当前时间是否处于该课程的选课时间段内不是简单的看数据库里状态字段而是动态比对时间。因为课程状态是可以由时间自动推进的比如22点选课结束21:59学生提交选课请求还可以成功22:00整就会被拒绝。这个校验逻辑处理好了导师会认为你对业务场景的理解很到位。2.3 Uni-app与原生微信小程序的选型权衡热词里频繁出现uniapp这个必须提一下。uniapp的跨端特性非常香一套代码可以编译到微信小程序、H5、App等多个平台对于想要同时拥有小程序端和Web端的毕设来说它甚至能帮你把教师管理后台也跑起来。但uniapp也有它的坑。最典型的是在微信小程序环境里部分浏览器端的API不存在很多组件的行为和H5端不一样你仍然需要去翻微信小程序的文档。我的结论是如果后端接口设计得好前端用什么框架影响不大选自己最熟悉的就行。我个人的方案是前端全部用原生微信小程序后端管理端用Vue这样前后端的技术栈区分很清楚。当时有的同学图省事管理端也想用微信小程序写结果调试管理端的复杂表格和弹窗时浪费了大量时间得不偿失。3. 数据库设计四张核心表怎么定义才能支撑整个系统数据库设计是毕设论文里的重头戏也是答辩老师一眼就能看出水平的地方。体育选课系统的表结构不算复杂但表的字段设计、索引设计和关系设计必须经得起推敲。3.1 核心表结构逐张拆解我设计的核心表一共四张外加几张辅助表。第一张是用户表字段包含用户ID、学号工号、姓名、密码、角色类型、院系、班级、手机号、头像URL、创建时间。密码不能存明文我当时用BCrypt做了加密处理这个在答辩时也是一个加分项。第二张是课程表字段包含课程ID、课程名称、课程类型篮球/足球/羽毛球/游泳等、任课教师ID、上课时间、上课地点、总名额、已选人数、学分、选课开始时间、选课结束时间、课程状态、课程简介。第三张是选课记录表字段包含选课ID、学生ID、课程ID、选课时间、退课时间、选课状态。状态字段我设计的取值有已选、已退、已结课这样即使学生退过课历史记录也不会完全消失对后续的选课统计有重要作用。第四张是公告表字段包含公告ID、标题、内容、发布人ID、发布时间、置顶状态。这里有一个很多新手容易犯的错误就是把“已选人数”直接当成一个普通字段在每次选课成功后就“读出来、加一、写回去”这种操作方式在高并发选课场景下会出大问题。正确的做法是选课成功的标志是成功插入一条选课记录而课程表的“已选人数”要么用数据库触发器维护要么在事务里基于课程ID做行锁更新。3.2 索引设计和ER关系怎么画才规范索引设计的核心思路是“查询频率高的字段建索引”。课程表的课程类型和选课开始时间字段、选课记录表的学生ID和课程ID字段这些是查询最高频的条件需要建立组合索引。选课记录表的唯一索引也很关键建在学生ID 课程ID上防止学生重复选修同一门课。ER图在论文里是必备内容。我当时用Power Designer画的包括学生、课程、教师、公告、选课记录这五个实体的属性以及它们之间的关系。比如学生和课程之间是多对多的选课关系通过选课记录表来体现教师和课程是一对多关系一个教师可以带多门课程。如果你对画图这件事不太熟练也可以用ProcessOn在线工具导出的图片清晰度足够放进论文。4. 小程序端核心功能实现登录、课程列表、选课交互小程序端的实现细节非常多哪些功能用微信生态的能力、哪些功能需要走自己的后端这里面的边界要清晰。我当时是从零开始一行一行写的WXML和JS虽然花费了不少时间但收获很大。4.1 微信登录与后端JWT鉴权的完整链路微信小程序的登录逻辑是很多人的第一道坎。我当时也踩过坑以为微信登录就是前端直接调用wx.login拿一个code就能完成登录其实不是。完整的链路是这样的前端调用wx.login获取临时凭证code再把code发给后端后端拿着这个code去调用微信接口服务获取用户的openid和session_key如果获取成功后端就用openid去用户表里查找该用户找到说明该学生已经注册过了没找到就额外创建一个用户最终后端签发一个JWT令牌返回给前端前端把它存储到wx.setStorageSync里。后面每次前端请求后端接口时都在请求头里带上这个JWT令牌后端通过拦截器解析令牌获取当前登录用户的身份信息。需要注意的是JWT令牌有一个有效期我当时配置的是7天过期之后前端必须重新走一遍登录流程。这个方案既保证了安全性也不会频繁打扰用户。4.2 课程列表的分页加载与下拉刷新课程列表页是学生打开系统后的主页面数据量虽然不算特别大但良好的体验感很重要。我这里做了两个优化第一个是分页加载每页固定10条数据实现“上拉加载更多”的效果第二个是下拉刷新重新拉取第一页数据。小程序端使用onReachBottom监听触底事件使用enablePullDownRefresh开启下拉刷新配置。逻辑实现上每次请求接口时传pageNum和pageSize两个参数后端返回一个“分页对象”包含当前页码的数据列表、总条数和总页数。前端拿到数据后追加到已有数组的尾部通过wx.nextTick保证渲染完成后再停止加载动画。在列表页还有一个筛选功能学生可以根据课程类型篮球、足球、羽毛球和上课时间段来过滤课程。这个筛选功能在前端做筛选是需要一次性把当前页所有数据载入的我当时没有偷这个懒而是把筛选条件提交给后端通过查询参数做条件过滤这个方案在数据量大之后依然能保持稳定。4.3 选课和退课交互中的状态把控选课的交互流程比表面看起来要复杂。学生点击某门课程的“选课”按钮前端不能直接就提交而是要弹出一个确认对话框展示课程名称、上课时间、学分和课程简介提醒学生确认无误后再选。确认之后前端发起选课请求此时有几个常见的返回结果选课成功、名额已满、选课时间未到、选课时间已结束、已经选过这门课、和其他课程上课时间冲突。这些状态码在后端接口里都做了统一封装前端拿到返回结果后分别进行提示。退课的流程也同样需要确认而且退课成功之后前端要立刻更新课程列表里剩余的名额数字。这里注意一个小细节退课时不能只在前端把界面上的数字减一而是要在退课接口返回成功后再重新请求一下该课程的详情数据让界面显示后端真实的数量。我当时在退课功能上线后测试时发现如果退课后不刷新界面显示名额是实时的但再次请求后发现数量可能已经变了因为同时有其他同学在选课——所以“以服务器为准前端只负责展示”这条开发原则非常关键。5. 后端Java核心逻辑并发选课与接口设计后端是整个系统的发动机所有关键的规则都在这层做。很多同学的毕设代码里面后端就是薄薄一层所有逻辑都堆在Controller里这种写法在答辩时非常容易被挑毛病。一个合格的Spring Boot工程应该经过Controller层、Service层、Mapper层这样的清晰分层。5.1 基于Spring Boot的分层架构实践我当时的后端工程结构是这样划分的controller包接收前端请求进行参数校验。service包承载核心业务逻辑比如选课、退课、课程发布。mapper包使用MyBatis-Plus操作数据库。entity包数据库表对应的实体类。dto包接收前端参数的传输对象。vo包返回给前端的数据对象。分层的好处是职责清晰比如选课接口从Controller进入后CourseService.selectCourse方法内部要执行很多步骤校验课程是否存在校验选课时间是否开启校验是否重复选课校验名额是否已满校验上课时间是否冲突最后插入选课记录并更新名额。这一连串的逻辑如果全塞在Controller里面整个方法会非常臃肿也不方便写单元测试。5.2 并发选课场景下的数据一致性保护学生集中抢课的时候多个请求同时到达后端如果不对数据做并发保护就一定会出现“超选”现象这是整个系统最容易翻车的地方。我当时查阅了不少资料最后整理了三种可行的方案。第一种方案是数据库层面的悲观锁使用SELECT ... FOR UPDATE锁住课程记录强制串行化对同一门课程的操作。优点是实现简单缺点是并发性能差同一门课程每秒能处理的选课请求有限。第二种方案是乐观锁在课程表中添加版本号字段更新名额时校验版本号是否被其他事务修改如果版本不一致则重新读取数据再操作。这个方案性能好但在人多的时候容易出现更新失败需要做重试处理。第三种方案是直接UPDATE扣减利用UPDATE语句的原子性“UPDATE course SET selected_count selected_count 1 WHERE id #{courseId} AND selected_count total_count”并检查受影响行数。如果受影响行数为0说明名额已经满了或者数据有误再执行回滚。我最终在正式代码里用的是“先INSERT选课记录再UPDATE扣减名额底层通过数据库唯一索引兜底重复选课”这一套组合方案三个措施加在一起既保证了用户操作的不重复性又保证了数据不会超发。5.3 接口统一返回体与异常处理机制前后端分离的开发模式下接口的返回格式如果五花八门前端联调会非常痛苦。我当时规定所有接口都必须返回一个统一的JSON结构状态码、提示信息和数据体。比如选课成功返回{ code: 200, message: 选课成功, data: null }名额已满返回{ code: 500, message: 该课程名额已满, data: null }。这个统一返回体配合Spring Boot的RestControllerAdvice全局异常处理器可以把业务异常、参数校验异常和系统异常分别做处理。我在业务代码里只需要throw new BizException(该课程名额已满)异常处理器会自动捕获并封装成标准格式返回给前端不用在每一个接口里都写try-catch代码干净了不少。6. 管理端功能教师排课与管理员的日常维护管理端虽然看起来没有学生端那么有视觉冲击力但在整个系统里占据了一席之地。没有管理端课程数据从哪里来教师账号谁来维护所以这部分功能要做扎实。教师端最核心的功能是课程管理。教师登录后能看到自己名下的课程列表可以新增课程也可以编辑已有课程的信息。新增课程时需要注意一个业务规则同一时间段该教师不能被安排两门不同的课程这个校验我在后端Service层做了防止前端漏传参数导致脏数据。管理员端的功能则更多一些。管理员可以创建教师账号、重置教师密码、查看所有课程以及选课人数、生成选课统计报表、发布站点公告。这里面有一个小功能容易被忽略就是“学生选课记录的导出”。我当时用了EasyExcel工具库把选课列表导出成Excel文件虽然写起来只是几行代码但答辩演示的时候效果很好老师会觉得你考虑到了实际使用中的真实需求。7. 常见问题与排查技巧实录毕业设计的过程本质上是踩坑和填坑的过程我把自己当初最常遇到的几个问题整理出来给正在做的你当参考。问题一开发环境中请求后端接口小程序一直提示“request:fail”。这个问题绝大多数情况下是域名白名单和HTTPS证书的问题。开发调试时在微信开发者工具里勾选“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”就能解决。但要发布上线的话必须配置备案域名并部署HTTPS证书。问题二用户登录后过一段时间再操作一直提示“登录已过期”。原因是JWT令牌过期了。我当时的处理是前端在请求拦截器里判断HTTP状态码如果是401就跳转重新登录同时自动调用wx.login重新获取新令牌保持用户无感刷新。问题三选课并发测试时发现有名额超发。后来检查发现是我在更新“已选人数”时先SELECT再UPDATE中间存在时间窗口。改成前面提到的原子UPDATE后问题才真正解决。这个坑也让我明白了为什么说“检查再更新”是最容易产生并发问题的写法。问题四真机预览时图片加载不出来。原因是微信小程序在真机上不能访问本地IP的图片资源必须使用HTTPS的图片地址。我当时把所有图片都传到了服务器上换成了线上地址才解决。我印象最深的一个排查过程是在模拟大量用户同时选课时系统频繁报“数据库连接池不够用”的错误。那是因为我默认的HikariCP连接池最大连接数设置太小而每个选课请求因为事务还没提交占用的连接一直被持有导致后续请求只能排队等待。后来我把最大连接数调大同时优化了事务的范围让事务尽量早地提交问题才彻底缓解。这类问题在毕设答辩时很有故事性因为说明你真的做了并发测试原因分析也能讲得头头是道。8. 项目扩展与答辩加分技巧如果你想让这个毕设的完成度更高一点或者希望答辩时让老师眼前一亮建议可以考虑从这几个角度做二次扩展。8.1 技术维度的升级方向缓存层面可以把课程列表数据放进Redis设置60秒过期时间减少数据库的查询压力。选课成功后异步把选课记录同步到数据库同时把缓存中的已选人数做原子自增进一步提升系统的并发处理能力。消息推送层面学生选课成功或者退课审核通过后通过微信小程序的订阅消息功能给学生发送一条通知。这个功能需要在小程序后台申请模板消息权限并引导用户授权订阅恰好能够体现你对微信生态的了解程度。数据可视化层面管理端可以加入一个简单的图表页面用ECharts展示不同体育课程的选课人数占比、各院系学生的选课偏好等统计信息。8.2 论文和答辩的侧重点写论文的时候架构图、流程图和ER图这些肯定不能少但真正的加分项在于你对核心问题的反思。我当时在论文里用了一整节来写“高并发选课场景下的数据一致性方案选型”从业务背景、存在问题、方案对比例表、最终效果这四个方面做了完整分析。论文里这个部分让老师在答辩时花了很多时间提问但我每一个细节都能对上最后反而成了整个项目的亮点。答辩展示的时候建议准备两条演示路径。一条是正常路径完整展示学生从登录到选课成功的业务流程另一条是异常路径比如选课名额已满会提示什么、选课时间未开始会提示什么。主动演示异常情况会让老师觉得你对边界情况有考量而不是光做了个快乐路径就草草了事。8.3 最后再分享一点个人建议体育选课系统这个题目虽然不奢华但它是一个真正的“麻雀虽小五脏俱全”的项目。我在做完这个项目之后对Spring Boot的后端分层、微信小程序的登录机制、数据库事务和并发控制都有了成体系的理解后续找实习面试时很多Java相关的题目我都能从这段经历里找到对应的案例来讲。建议你整个项目周期尽量留出七八周的时间自己独立编码、独立调试、独立写文档。代码可以借鉴别人的思路但最后一定要完全吃透。你从图书馆、从博客、从开源项目里找到的任何参考代码都一定要一条一条去理解它的逻辑再根据自己的需求去改。只有真正亲手敲过的代码在答辩时才能自信地讲出来否则老师随便问一个变量为什么这么写你就可能卡壳了。