陈小严带过三十多份课程设计和毕业设计的代码，我越来越确定一件事：Spring Boot + 微信小程序这套组合，确实是现阶段做“管理系统/服务类平台”类题目最稳的路线。原因无他——后端生态成熟、学习资料密度大、面试和答辩都有话聊，而小程序端又天然贴合移动场景，尤其适合“培训机构课后托管系统”这种需要家长、老师、学生多方角色参与的项目。今天我就拿这个“基于Spring Boot的培训机构课后服务平台小程序 / 小学生课后托管系统”为题，把从需求拆解到数据库设计、后端接口、小程序联动、再到答辩备稿的完整链路拆开讲一遍。想要拿它做课程设计、毕业设计，或者干脆想学一套完整的全栈项目实战思路的同学，可以对照着直接动手。
先说一句大实话：这类系统真正难的点，从来不是“写代码”，而是“把需求理清楚，再按业务逻辑把表结构建对”。业务关系一旦理顺，后面所有功能开发都是水到渠成的事。这篇博文会按我实际改项目时的顺序来写——先梳理业务和组织功能，再聊技术选型为什么这么定，然后重点展开数据库七张核心表、后端接口设计、小程序端关键实现，最后附上一份答辩高频问题应对清单。全文偏实战，没有一句废话。
1. 这个系统到底做什么：需求拆解与选题价值分析
1.1 一个课程设计题目的真实分量
很多人拿到这个题目第一反应是“又是个管理系统”，然后就开始堆功能：用户管理、课程管理、订单管理、公告管理……但如果你只是堆CRUD（增删改查），这篇博文对你一点用都没有。我要说的是，怎么做才能让它成为一个“有业务逻辑”的毕业设计，而不是“增删改查的搬运工”。
从标题看，这个系统叫“培训机构课后服务平台小程序”，同时也叫“小学生课后托管系统”。这两句话连在一起，真实场景其实非常具体：家长下班晚，孩子放学后没人接，所以把孩子送到培训机构或托管中心。机构提供课后托管服务，包括作业辅导、兴趣课、临时托管，家长线上选课、报名、缴费、查看孩子签到情况，老师端负责排课、签到、布置作业，机构管理员负责审核和统计。
这就不只是一个“课程列表+下单”的电商系统。它有三个明显特征：
- 角色多且权限分明：家长、学生、老师、机构管理员，不同角色看到的数据和操作完全不同。
- 线下线上有联动：选课、缴费发生在线上，签到、作业反馈发生在线下，系统要承接这两段流程。
- 有时间维度的业务：托管服务是按“学期/月份/课时”来卖的，涉及排课冲突、签到记录、次数扣减，这不是简单的订单状态机。
所以，选题价值就是：难度适中、技术覆盖面广、业务有延伸空间。背靠Spring Boot做REST API，小程序做前端，MySQL存业务数据，该有的都有了，而且答辩时能讲的东西非常密。
1.2 核心角色与用户故事：从“谁在用”反向推导功能
我在给同学梳理需求时，习惯先写用户故事，再倒推功能列表。这个项目至少可以拆出四个角色、八个核心故事：
| 角色 | 核心诉求 | 对应功能模块 |
|---|---|---|
| 家长 | 查看课程、下单报名、查看孩子签到、接收通知 | 课程浏览、报名支付、签到查询、消息中心 |
| 学生（小学生） | 查看自己的课表、提交作业、确认已签到 | 我的课表、作业提交 |
| 老师 | 创建课程、发布排课、上课签到、布置作业 | 排课管理、签到管理、作业管理 |
| 机构管理员 | 审核老师、课程上下架、查看营收数据 | 审核管理、数据统计 |
有了用户故事，你会立刻发现，“报名”这个动作不是一个简单的INSERT语句，它后面牵扯着课程名额扣减、订单状态流转、报名成功后要生成“学生课程关系记录”，同时还可能要给学生账户生成“剩余课时数”。这一个点就够你在论文“核心业务逻辑设计”那一章写满两页。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么是Spring Boot + 微信小程序：选型背后的现实逻辑
2.1 技术选型：不是越新越好，而是越稳越好
先说后端框架。Spring Boot 我建议直接用 2.7.x，不追最新版本。原因有两条：一是网上资料和踩坑记录最密集，遇到奇怪问题一搜就有答案；二是很多中间件、starter（比如MyBatis-Plus、Sa-Token）对2.7的兼容性是被验证过的。如果你用Spring Boot 3.x，Java版本要求、javax到jakarta的包名迁移，很可能在课程设计阶段就白白耗掉两周时间。
持久层我推荐 MyBatis-Plus，不是JPA。理由是：MyBatis-Plus在答辩时更容易讲清楚SQL是怎么写的、逻辑是怎么控制的，而且它的BaseMapper能让单表CRUD工作量降一半。这个项目里稍微复杂一点的查询（比如“查某位老师某天的所有排课”）直接自定义SQL，可控性很强。
小程序端就用原生微信小程序，不引入Uniapp。为什么？因为课程设计阶段，原生小程序足够覆盖需求，而且不用额外学习跨端框架的编译问题。页面数量控制在15个左右，原生原样完全吃得消。如果你非要上Uniapp，一旦遇到组件兼容性坑，调试成本反而更高。
数据库选 MySQL 8.0，存储引擎InnoDB，字符集utf8mb4。到这里，技术栈就是一句很经典的话：Spring Boot负责提供接口和业务逻辑，MySQL负责数据持久化，微信小程序负责移动端交互。
2.2 前后端分离的项目分层与目录结构
我见过很多同学习惯把所有代码堆在Controller里，图省事。这个习惯在这次项目里必须改。三层架构要明确分开，目录结构我建议这样设计：
text复制com.example.tuoguan
├── controller // 接收请求、参数校验、返回结果
├── service // 业务逻辑层，核心判断都在这里
├── mapper // MyBatis-Plus 数据访问接口
├── entity // 数据库实体类
├── dto // 前端传参对象，避免实体类直接暴露
├── vo // 返回给前端的数据封装
├── config // 拦截器、WebMvc配置、跨域配置
├── utils // JWT工具、统一返回结果工具
└── common // 异常处理、常量定义
这样的好处是：答辩时老师让你画架构图，你随手就能画出来；代码查错时也能快速定位是“参数接错了”“业务写错了”还是“SQL写错了”。分层这件事，本身就是课程设计考察的一个隐性得分点。
3. 数据库设计：七张核心表与关键字段背后的业务考量
3.1 表结构一览：先看全局再看细节
我设计数据库的习惯是：“先画表间关系图，再定字段”，关系图建议用纸笔画，比如：家长-学生是1对多（一个家长可以绑定多个孩子），学生-课程是多对多（一个学生报多节课，一节课有多个学生），这就意味着需要中间表student_course来衔接。课程和排课是1对多，排课和签到是1对多。
最终核心表定为七张，外加几张辅助表：
| 数据表 | 核心用途 | 关键字段 |
|---|---|---|
user |
用户统一表（家长/学生/老师/管理员，用role区分） |
id, openid, name, role, phone, avatar |
course |
课程信息表 | id, title, cover, price, total_hours, status, teacher_id |
schedule |
排课表（某次课的上课时间地点） | id, course_id, teacher_id, start_time, end_time, room, max_students |
student_course |
学生选课关系表 | id, student_id, course_id, remain_hours, status, create_time |
order |
订单表 | id, order_no, user_id, course_id, amount, pay_status, pay_time |
attendance |
签到表 | id, schedule_id, student_id, status, sign_time |
homework |
作业表 | id, schedule_id, title, content, deadline, submit_status |
3.2 关键字段为什么这么设计
第一，用户表必须存openid。 小程序登录的核心是wx.login()拿到code，后端拿着code调用微信接口换openid。Openid就是小程序用户的“身份证”，业务里所有的登录校验都围绕它展开。很多同学把用户名密码硬编码进去，这在课程设计里虽然能跑，但答辩时一旦被问到“小程序怎么登录”，容易露怯。
第二，订单金额不要用float，用Decimal。 这不是什么高深原则，就是钱这种敏感数据用浮点类型会出现0.1 + 0.2 = 0.30000000000000004的问题。MySQL里的DECIMAL(10,2)，Java里的BigDecimal，两头配合好，缴费逻辑不会出诡异错误。
第三，student_course表里必须加remain_hours剩余课时字段。 这是托管类系统区别于电商系统的重要地方。家长买的不是“一次性商品”，而是“一段时间内可消耗的课时服务”。每上完一节课，签到完成后就要同步扣减一次remain_hours。这个字段在答辩时能帮你引出“事务”和“并发扣减”两个重要话题。
第四，排课表要设计好唯一约束。 同一间教室同一时间段不能排两节课，这是基本要求。可以在schedlue表加一个逻辑判断：插入前查一次是否冲突，同时给(room, start_time, end_time)建联合索引，查得快还能做防重。面试官最喜欢问的“如何防止并发重复排课”，答案就在这。
4. 后端核心模块实现：JWT登录、接口规范与关键业务代码
4.1 基于JWT的登录态与权限控制
小程序端用wx.login静默获取code，后端拿到code后调用微信接口换取openid和session_key，这一套流程要封装好。之后不能每次请求都调微信接口，所以后端要用openid签发一个**JWT token**返回给小程序端。小程序端之后每次请求把token放在请求头Authorization里，后端用一个拦截器统一校验。
拦截器里这一步是核心：
java复制public class JwtInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
String token = request.getHeader("Authorization");
if (token != null && token.startsWith("Bearer ")) {
token = token.substring(7);
}
try {
Claims claims = JwtUtil.parseToken(token);
request.setAttribute("userId", claims.get("userId"));
request.setAttribute("userRole", claims.get("role"));
return true;
} catch (Exception e) {
response.setStatus(401);
response.getWriter().write("{\"code\":401,\"msg\":\"登录已过期\"}");
return false;
}
}
}
有一个坑必须提醒：小程序端不会自动跳登录页。微信小程序是静默登录，没有浏览器那种重定向流程，所以前端必须在收到401响应时主动wx.reLaunch到登录页。否则用户会感觉“点了按钮没反应”，这个很影响评阅体验。
4.2 接口设计规范：统一返回体
接口建议统一返回格式：
json复制{
"code": 200,
"message": "成功",
"data": {}
}
确定统一返回体后，写一个Result类，Controller里所有接口都返回它。这样小程序端做响应拦截时只需判断code，不需要对每个接口单独写错误解析。这个习惯看着小，但对整个项目代码风格统一帮助巨大。
4.3 报名选课业务的“事务+并发”实现
这个模块是整个项目最核心的业务点。家长点击“立即报名”后，后端要做几件事：
- 校验课程状态是否上架
- 校验当前报名人数是否小于课程容量
- 创建订单，状态为“待支付”
- 模拟支付成功后更新订单状态
- 往
student_course插入选课关系记录
这几步必须放在同一个事务里。我的建议是用@Transactional注解在CourseService.enroll()方法上，并在插入前用UPDATE course SET stock = stock - 1 WHERE id = ? AND stock > 0这种带条件的SQL保证超卖不会发生。如果更新影响行数为0，说明名额已被抢完，直接抛业务异常。
讲真，“数据库层面控制并发防超卖”这句话，写在论文里、放在答辩里，完全能达到“老师的眼睛会亮一下”的效果。因为大部分课程设计只会做单线程串行逻辑测试，你能主动考虑并发场景，说明思维已经不只是“写API”。
4.4 签到扣减课时：写操作必须同步数据
老师在小程序端点击“签到”按钮时，后端要做三件事：
attendance表插入一条签到记录student_course表把remain_hours减1- 如果本次课是当天最后一节，自动通知家长
这里同样要用事务。而且我认为签到接口的返回信息应该更丰富，比如返回学生当前的剩余课时，方便前端展示给家长。这种细节是评审老师比较认可的“业务纵深”。
5. 小程序端的关键实现：从页面结构到登录态同步
5.1 页面划分：按用户角色拆出三个Tab
小程序端可以直接按角色拆页面。我设计的结构大致是：
text复制pages/
├── login/ // 登录页面，首次进入的落地页
├── index/ // 首页：课程列表
├── courseDetail/ // 课程详情 + 选课按钮
├── my/ // 个人中心
├── order/ // 订单列表
├── attendance/ // 家长查看孩子签到记录
├── homework/ // 作业列表与提交
├── teacher/
│ ├── scheduleManage/ // 老师排课首页
│ ├── qrcodeSign/ // 签到页（可以生成二维码由学生扫码）
│ └── homeworkReview/ // 作业批改列表
首页的课程列表用wx.request加载后端接口，下拉刷新用enablePullDownRefresh，触底加载用onReachBottom。这两个交互细节会让小程序很加分，因为大部分课程设计小程序连下拉刷新都不做，体验差距一眼就看出来了。
5.2 请求封装：不要每个页面对着一堆wx.request裸调
小程序端最忌讳的就是每个页面直接写wx.request，到处重复代码。我在项目里会先做一个request.js统一封装：
javascript复制const request = (url, method, data) => {
return new Promise((resolve, reject) => {
wx.request({
url: baseUrl + url,
method,
data,
header: {
'Authorization': 'Bearer ' + wx.getStorageSync('token')
},
success: (res) => {
if (res.data.code === 401) {
wx.reLaunch({ url: '/pages/login/login' })
return
}
resolve(res.data)
},
fail: (err) => reject(err)
})
})
}
这个封装至少有两大好处：一是所有接口统一携带token，二是统一处理401跳登录页。以后你想统一打印日志、统一做loading动画，只需要改一个文件，非常省事。
5.3 登录态同步：从微信code到后端JWT的闭环
登录页最好做到“进小程序就自动登录”，你不需要用户填手机号（小程序也没法填）。正确的流程是：
wx.login()拿到code- 调用后端
/api/auth/login接口，传code - 后端用code换openid，查
user表，如果存在就签发JWT；如果不存在就自动注册一个用户（默认角色是家长） - 返回token，前端存到
wx.setStorageSync('token', token)，然后跳首页
首次注册时还可以顺便引导家长填写孩子信息和手机号。这个小流程是符合微信生态惯例的，同时也让演示时非常顺滑——“打开小程序直接把课程列表展示出来了”，比“先登录、再输密码、再进首页”体验好太多，答辩演示环节很占便宜。
6. 文档与答辩：万字文档怎么布局，老师最爱问哪几个问题
6.1 论文章节设计："序-需-设-实-测-结"六段式
“附万字文档”是标题里明确提到的交付物。论文不要临时凑，最好项目开发前就把骨架搭好。我给常用框架是一个六段式：
| 章节 | 核心内容 | 建议篇幅 |
|---|---|---|
| 绪论 | 选题背景、国内外现状、研究意义 | 1500字左右 |
| 需求分析 | 可行性分析、角色分析、功能用例、业务流程 | 2000字左右 |
| 系统设计 | 架构图、ER图、表结构、接口设计 | 2500字左右 |
| 系统实现 | 核心模块截图与关键代码说明 | 3000字左右 |
| 系统测试 | 测试用例表、测试结果、问题修复过程 | 1500字左右 |
| 总结与展望 | 个人收获、不足、未来可扩展方向 | 500字左右 |
写论文时记住一个重要原则：千万不能写成代码说明书。一段代码贴出来，必须配一段“为什么这么写”的文字。如果你的代码块后面没有任何解释，老师基本默认你是从哪复制来的。比如上面那个JWT拦截器，你就要接着写：“这里使用拦截器而不是在每个Controller方法里重复校验，目的是统一登录态处理逻辑……”这样的话一多，论文深度自然就上来了。
6.2 答辩高频追问与参考思路
根据我带过学生的反馈，这个项目答辩时被问最多的问题，答案是必须提前背下来的：
问题1：你为什么选择Spring Boot？
参考思路：Spring Boot简化了SSM（Spring + SpringMVC + MyBatis）的配置，内置Tomcat，能快速构建独立运行的微服务应用；配合大量starter生态，能够让我们把主要精力放在业务而不是框架配置上。另外Spring Boot的自动配置和约定优于配置的设计理念，非常适合快速迭代的中小型项目。
问题2：JWT和传统Session有什么区别？你们为什么用JWT？
参考思路：Session是服务端存储会话状态，需要维护会话id，不利于横向扩展；JWT是无状态的，服务端不需要保存会话，token自身携带用户信息，通过签名保证安全。对前后端分离和小程序场景来说，JWT更合适，也容易做分布式扩展。
问题3：怎么防止课程超卖/重复选课？
参考思路：下单前先校验库存，但校验与扣减必须原子化。具体做法是使用带条件的UPDATE course SET stock = stock - 1 WHERE id = ? AND stock > 0，如果影响行数为0说明库存不足；同时添加student_course表唯一索引(student_id, course_id)作为第二道防线，即使并发时两个请求同时进来，数据库层面也能拒绝重复关系。
问题4：如果数据量变大了，你会怎么优化？
参考思路：先从索引下手，对高频查询字段加索引，比如订单表按家长id建索引、课程表按状态和上架时间建索引；然后做读写分离，把统计报表类查询放到从库；最后考虑Redis缓存热点课程信息、用消息队列削峰处理报名高峰。说这三层，足够应对大多数追问。
问题5：这个小程序怎么做到前后端联调的？
参考思路：真机预览时，开发者工具里勾选“不校验合法域名”，将后端接口地址指向本地计算机局域网IP，同时后端配置跨域。正式部署时把小程序request的合法域名配置为服务器域名，按HTTPS部署后端接口即可。这里要重点提一下“请求封装统一处理401”，老师听到这种细节会认为你真的做过联调。
我个人带学生改这个题目的经验是：只要你把第4章那个报名选课业务、第3章那双层防重的数据库设计、第6章那段答辩表达逻辑都真正理解到位，剩下的功能实现都是工作量问题，不是难度问题。代码写得乱不重要，重要的是你能讲清楚“为什么这样做”。这八个字，才是一个课程设计/毕业设计最值钱的地方。
最后再分享一个小技巧：如果时间充裕，给项目做一个“数据看板”页面，把每天的报名人数、课时消耗总量、营收趋势统计出来，用ECharts在小程序端渲染。功能不复杂，但展示效果非常炸。很多评审老师对“统计图表”的印象分天然就高，因为这说明你已经不是单纯在做增删改查了。祝各位顺利过审，有问题堆到评论区，我看到会回。