先说明一下我的底子。这个项目我前后花了两周时间才彻底跑通期间踩了不下二十个坑有数据库字段设计失误的有小程序真机调试连不上后端的还有部署上线时HTTPS证书没生效导致接口全部报错的。所以这篇不光是把代码堆出来给你看更想把为什么要这么做以及哪些地方最容易翻车讲清楚让你少走点弯路。先说这个系统的定位。它是一套面向培训机构和课后托管班的管理服务小程序核心使用方有三类家长、机构老师、平台管理员。家长在小程序端完成选课、报名、缴费、签到、查看剩余课时机构端在后台维护课程、班级、排课、学生考勤平台管理员做数据审核和统计分析。说白了就是用一个微信小程序把机构招生-家长报名-上课签到-课时消耗-续费提醒这条闭环打通。适合谁来参考如果你是做毕业设计或者课程设计这个项目涵盖了完整的前后端分离、微信小程序开发、数据库设计、鉴权体系、文件存储、支付对接答辩时能讲的东西非常多。如果你本身就在做类似的培训/托管的SaaS系统那这套数据模型和状态机设计也能直接借鉴少走不少弯路。1. 整体设计与核心需求拆解1.1 这套系统到底解决了什么业务痛点先说行业背景再做技术选型这样才能明白为什么功能模块这么划分。课后托管和培训机构的日常运营里三个角色各有痛点。家长最头疼的是不知道孩子几点下课、有没有安全到机构、课上表现怎么样、课时还剩多少——每次都得打电话问前台体验很差。机构的痛点在于排课和考勤全靠Excel甚至纸质记录月底统计老师课时费的时候一层一层核对费时容易错。平台管理员则面临多门店数据割裂、无法直观看到各机构的运营情况。所以这个系统的核心需求可以拆成四块家长端注册登录、浏览机构课程、下单购买课时包、预约排课、每日签到签退、剩余课时和消课记录查询老师端查看我的班级和课表、为学员操作签到/签退、提交课后反馈机构管理员课程和班级的增删改查、学生档案管理、排课、订单和退款处理、营收统计平台端机构入驻审核、课程上架审核、全局数据看板明白了业务需求再回头看技术选型和数据表设计就会非常顺——表结构怎么建状态字段怎么定义完全由业务流程决定。1.2 为什么选 SpringBoot 小程序原生 MySQL先说后端框架。SpringBoot 在这个场景是绝对主流这一点毋庸置疑。相比 SSM 传统项目SpringBoot 的自动装配省掉了大量 XML 配置内嵌 Tomcat 支持一键打包成 jar部署时只需要java -jar一条命令。对毕设和课设来说答辩现场把项目启动起来演示这一个优势就能省掉很多不必要的紧张。版本上我推荐SpringBoot 2.7.x而不是 3.x。很简单3.x 要求 JDK 17而很多学校机房、云服务器环境还停留在 JDK 8。更重要的是教程、依赖、排错方案里 2.x 的资料占了绝大多数——真到了卡壳的时候你能搜到的答案基本都是 2.x 体系的踩坑成本低得多。小程序端我选了微信原生开发而不是 UniApp。原因有三第一原生框架对微信 API 的支持最直接没有中间层封装带来的兼容问题第二出错排查效率高wxml / wxss / js 结构清晰不像跨端框架那样要经过一层编译转换第三答辩演示的时候原生开发者工具打开即跑真机预览调试也方便。当然如果机构后续要发支付宝小程序或者抖音小程序那引入 UniApp 是合理的——但就这个项目场景而言原生就够用了。数据库用 MySQL 8.0配合 MyBatis-Plus。选 MyBatis-Plus 不选纯 MyBatis是因为 CRUD 占了业务的大部分MP 的 BaseMapper 帮你把单表增删改查写好了省出来的时间完全可以投入到关联查询、报表统计这些更具业务价值的部分。分页插件、条件构造器这些能力也很成熟适合中小型系统。2. 数据库设计一张图看懂全链路2.1 核心表结构与字段设计的思路数据库是整个项目的基石表建错了后面改起来非常痛苦这是我从这次实践中得到的最深体会。下面直接给出这套系统的核心表清单每张表附上设计说明。用户表user涵盖家长、老师、机构管理员、平台管理员四类角色通过 role 字段区分。注意手机号要加唯一索引登录时既要支持手机号密码也要支持微信授权所以 openid 和 unionid 字段要预留。密码使用 BCrypt 加密存储初始密码建议设置为手机号后六位。机构表institution机构名称、营业执照号、联系人、联系电话、地址、封面图、审核状态。审核状态建议用数字0待审核 / 1通过 / 2驳回。机构入驻后机构管理员与机构绑定institution_id权限隔离就靠这个外键。课程表course课程名称、封面图、课程简介、适合年龄段、上课时长、机构ID。这里要特别注意不要直接把价格放进课程表——因为同一个课程可以有不同的课时包比如20课时包和50课时包价格是挂在课时包上的。课时包表course_package课程ID、课时包名称、课时数、单价、总价、有效期。设计成课时包而不是课程直接定价是因为家长购买的是课时次数每次签到消耗1个课时这更符合课后托管的实际计费模式。订单表orders订单号、用户ID、课时包ID、实付金额、支付状态、下单时间、支付时间。订单号的生成规则建议是yyyyMMddHHmmss 4位随机数避免使用数据库自增ID直接当订单号否则容易被同行看出业务量。报名/购买记录表user_course用户ID、课时包ID、剩余课时、总课时、状态。这张表是查询我的课程和剩余课时的关键每次签到成功就对剩余课时做减一操作。班级表class_room机构ID、课程ID、班级名称、上课时间、上课地点、授课老师ID。一个课程下可以开多个班级不同时段的班级适合不同家长的需求。排课表schedule班级ID、上课日期、开始时间、结束时间、教室。排课是实现每周一三五下午4点到6点这类规律性课程的核心老师端按此表查看当天课表。签到记录表attendance学生用户ID、课程ID、班级ID、scheduleID、签到时间、签到方式老师代签/家长到店扫码、消耗课时数。每日签到签退形成考勤流水月末按机构汇总就是老师和机构的结算依据。2.2 状态机设计与金额处理两个容易翻车的细节第一个细节是状态字段的设计。你会发现业务里大量地方有状态这个字段订单支付状态、机构审核状态、课时包有效期状态。我的建议是统一用 tinyint 存数字备注里写清楚状态含义代码里用OrderStatus这样的枚举类来定义常量。别用字符串1、2也别用中文直接存否则查询和扩展都很难受。订单状态的流转可以定义成0待支付 → 1已支付 → 2已完成 → 3已退款。退款是一个商家发起的动作跟订单状态没有冲突因为退款金额记录在另外一张退款表中。这里有个细节用户申请退款时要检查该课时包是否已经产生了签到流水。如果已经上过课就不能原路全额退只能退剩余课时对应的金额——具体退多少由机构管理员操作平台只提供入口这个规则在设计文档里必须写明。第二个细节是金额的计算。强烈建议以元为单位使用decimal(10,2)类型金额计算统一在Java服务端完成。别把数据库里的计算逻辑写成 SQL 里的SUM(price)一是不利于维护二是脱离开业务规则后容易算错。更重要的是微信支付回调里返回的金额单位是分跟数据库元之间需要二次转换这个转换一定要做两次确认因为单位混用造成的金额错乱是支付系统里最高发的事故之一。如果你打算用整数分来存储也不是不行但所有运算必须注意单位。我个人更推荐 decimal(10,2)因为报表导出、人工核对的时候直接就是元的语义省心很多。3. 后端核心实现SpringBoot 项目的搭建要点3.1 JWT 鉴权、全局异常与统一返回体前后端分离后第一个要解决的是登录鉴权。我采用 JWTJSON Web Token方案用户通过手机号密码或微信授权登录成功后后端生成一个有效期为7天的 Token 返回给小程序的 storage小程序每次请求在请求头里带上Authorization: Bearer token后端通过拦截器校验。JWT 的好处是服务端无状态扩容部署时不需要共享 Session。但要注意两点Token 要设置合理的过期时间建议7天 30天续期的机制7天过期后携带旧 Token 访问续期接口签发新 Token避免用户每7天重新登录一次。敏感操作比如修改密码、退款审核要再校验一次防止 Token 被窃取后的滥用。全局异常处理我用了RestControllerAdvice统一处理业务异常、参数校验异常、未知异常。这样不管后端哪个环节抛异常前端wx.request的 fail 回调接收到的都是标准格式{ code: 500, message: 系统繁忙请稍后重试 }而不是一堆堆栈信息堆到前端。这个统一返回体的结构设计为{ code: 0, message: success, data: {} }code 为 0 表示成功非 0 表示各类业务错误。前端只需要判断 code 再决定走成功逻辑还是弹错误提示写起来非常省事。3.2 缓存、文件上传与定时任务课程列表、首页轮播图、机构介绍这些不常变化的数据我加了 Redis 缓存。为什么用 Redis因为它简单可靠、并发性能好而且在毕设答辩中能迅速体现你对系统架构的理解。缓存更新的策略是更新数据库时主动删除缓存而不是设置超时时间。加缓存的收益是首页接口从 400ms 的响应时间降到了 80ms用户体验有显著提升。文件上传我接入了 MinIO因为用本地磁盘存储有一个不好解决的问题——小程序端拿不到你本地电脑的 IP 地址真机预览时而且部署到服务器后文件存在本机磁盘上迁移很麻烦。MinIO 是开源的 S3 兼容对象存储部署简单一条 Docker 命令就能起来社区活跃免费授权对中小项目完全够用。头像、课程封面图、机构资质照片都通过 MinIO 来存返回给前端的是一个有效期内的访问 URL。定时任务这块处理了两件事一是超时未支付订单的自动关闭使用 Spring Task 的Scheduled(cron 0 */5 * * * ?)每5分钟扫描一次把创建超过30分钟仍未支付的订单改为已关闭同时释放课时库存名额二是签到提醒每天早上8点给当天有课的家长推送订阅消息提醒准时到校。这些如果你要自己写注意订阅消息的模板 ID 和用户授权要前置处理否则推送会失败。3.3 分页查询与多条件筛选的落地写法列表查询是这个系统的重头戏——课程列表、订单列表、签到记录全部都是分页多条件筛选。我使用的 MyBatis-Plus 分页插件配合 QueryWrapper 的 Lambda 表达式代码非常简洁PageOrder page orderMapper.selectPage( new Page(pageNum, pageSize), new LambdaQueryWrapperOrder() .eq(Order::getUserId, currentUserId) .eq(userId ! null, Order::getStatus, status) .orderByDesc(Order::getCreateTime) );需要注意 MyBatis-Plus 分页查询要先配置拦截器否则selectPage只能查全表然后内存分页数据量一上去就直接 OOM。配置分页插件的方式是Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }这个配置漏掉的人非常多一定要检查。另外多表关联查询比如订单列表要显示课程名和机构名不要直接在 Service 层用 QueryWrapper 硬拼 SQL可以让 Mapper 接口自己写Select的关联 SQL或者用 XML。我个人偏好 XML因为复杂 SQL 在 XML 里可读性强还能随时加条件注释。4. 小程序端从页面搭建到真机调试的完整记录4.1 小程序端技术架构与公共组件设计小程序的目录结构我建议按功能模块划分方便维护pages/ index/ // 首页机构列表、课程推荐、轮播图 course/ // 课程列表和详情 order/ // 订单确认页、支付 mine/ // 个人中心我的课程、剩余课时、签到记录 sign/ // 签到页 teacher/ // 老师端我的课表、学员签到 utils/ request.js // wx.request 封装携带 token、统一错误处理 auth.js // 登录、token 存取 components/ course-card/ // 课程卡片组件 empty-state/ // 空状态展示utils/request.js这个封装是整个小程序端的基石里面统一了这么几件事从 storage 取出 token塞进请求头统一处理 401 状态码token 过期时调用刷新接口把新 token 存好然后重放原请求网络错误弹 toast 提示业务错误码code 非 0统一拦截弹提示这个封装写好后所有页面发起请求只需要这样调用api.request({ url: /course/list, method: GET, data: { pageNum: 1, pageSize: 10 } }).then(res { // res.data 直接就是后端返回的 data 字段 }).catch(err { // 统一错误弹窗不用每个页面再写 });4.2 登录流程与鉴权接入小程序的登录不同于传统的账号密码登录要走微信的wx.login换 code然后后端拿 code 去微信接口换 openid。我的登录链路是这样用户首次打开小程序调用wx.login()获取临时 code将 code 发送到后端/user/login接口后端调用微信jscode2session接口拿 code 换 openid根据 openid 查用户表如果已注册直接签发 JWT如果未注册先自动注册默认角色是家长端用户再签发 JWT返回 token前端存到 storage后续请求都带上这里有个坑微信官方要求jscode2session必须由后端服务器调用不能在小程序端直接使用 AppSecret否则 AppSecret 会泄露。所以不要把 AppSecret 写进小程序代码里务必放在 SpringBoot 的application.yml中配置。如果用户需要绑定手机号名校验证或者机构内部系统登录场景可以走wx.getPhoneNumber授权后端拿到加密数据和 iv 后通过微信解密工具还原手机号完成绑定。整个流程在代码里比较长设计文档里我写了完整的时序图说明。4.3 抓包调试实战本地联调与真机预览的解决方案小程序开发中最容易卡住的就是本地联调。默认情况下小程序只能请求https://而且是已经在后台配置到合法域名列表里的接口。为了方便本地调试开发者工具右上角的详情-本地设置里有一个不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书的勾选开发阶段勾上它就可以直接请求http://localhost:8080了。但真机预览的时候就麻烦了手机上的小程序无法访问你电脑的 localhost。我的方案是在 SpringBoot 的配置文件中把接口地址配成电脑在局域网内的 IP比如http://192.168.31.100:8080并且让后端监听0.0.0.0server: address: 0.0.0.0 port: 8080同时真机调试时也要打开开发者工具的不校验合法域名选项在预览二维码页面勾选。这样手机和电脑在同一 Wi-Fi 下真机就可以直接访问后端接口了。另外一个非常实用的技能是小程序抓包。开发时遇到接口返回不符合预期的情况光靠 log 往往看不全抓包是最直接的手段。windows / mac 上用 Charles 或者 Fiddler 抓 HTTPS 包需要在代理设置里配置 SSL 代理并安装证书到手机。微信开发者工具自带「Network」面板可以看到所有 wx.request 的请求、响应头、响应体大多数情况下比外部抓包工具更方便。真机调试时的网络请求也可以在开发者工具里查看不过需要勾选真机调试-打开调试。抓包前后端联调时最常发现的问题有三个后端返回的 JSON 字段名和小程序端取的不一致后端用courseId前端写course_id日期格式问题后端返回2024-12-08 12:00:00前端需要在 js 里转成2024年12月8日展示后端返回了 null 字段前端用了它做运算导致 NaN这些问题统统可以通过抓包快速定位比瞎猜高效得多。5. 源码、数据库交付物怎么用才不吃亏5.1 拿到项目压缩包后的第一件事梳理目录结构不管是从网上下载的完整项目源码还是团队交接的代码库拿到手的第一件事一定是先看目录结构和 README而不是急着启动。一个规范的 SpringBoot 项目目录是这样src/ main/ java/com/xxx/edu/ config/ // 配置类RedisConfig、WebMvcConfig、MybatisPlusConfig controller/ // 接口层 service/ // 业务逻辑层 mapper/ // DAO层接口 entity/ // 实体类 common/ // 统一返回体、全局异常处理、工具类 security/ // JWT拦截器、登录、权限控制 resources/ mapper/ // MyBatis XML 文件 application.yml // 核心配置 sql/ // 初始化 SQL 脚本如果你的项目压缩包不带 README那就先看application.yml里的数据库配置把库名、用户名、密码记下来再去sql/目录找初始化 SQL 脚本跑一遍。之后启动项目浏览器访问http://localhost:8080/doc.html如果是 Swagger 或 knife4j 做了接口文档就能直接看到所有接口列表用 Postman 或者小程序模拟器逐个测。我强烈建议你在答辩前手动调一遍所有接口别只看代码。因为仪表盘上显示的数据和你实际操作时产生的数据可能对不上提前跑通真实数据流答辩演示时才不会卡壳。5.2 拿到 jar 包反编译排查问题与学习他人代码的技巧有同学问怎么把一个 SpringBoot 的 jar 反编译回项目源码。这个需求在毕设里其实很常见——你拿到手的源码因为各种原因编译不过或者你手里的只有 jar 包需要把代码还原出来改功能。核心步骤是这样下载 JD-GUI 或者在 IDEA 里安装 Java Decompiler 插件IDEA 自带反编译能力直接打开 class 文件即可查看把 jar 包解压找到BOOT-INF/classes/目录下的com/目录这里的 class 文件就是编译后的代码用反编译工具逐个打开 class把关键类保存成 java 源码对照BOOT-INF/lib/下的依赖 jar把 pom.xml 里的坐标写完整否则反编译出来的源码没法 mvn 打包说实话反编译只能作为学习参考和问题排查手段因为反编译出来的代码会有很大的信息损失变量名被混淆变量 a、b、c注释全部丢失泛型和枚举判断可能被还原成 switch 或 if-else。想真正改造一个项目还是建议尽量找到原始源码或者以原始源码为基础做增量开发。反编译更适合的场景是系统某个接口报错你想看看打出来的 jar 包里这个类具体逻辑和源码是不是一致、是不是自己改漏了。用它来对账效率很高。5.3 数据库脚本与数据迁移的实践建议项目里的sql初始化脚本包含基础表结构和演示数据。如果要在自己电脑上复现流程是本地 MySQL 建库CREATE DATABASE edu_assistant DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;执行项目提供的xxx.sql脚本导入表和数据修改application.yml里的数据源地址把 username / password 改成你自己的启动后端验证数据能正常查出来如果本地运行没问题但要部署到云服务器那就涉及数据库迁移。这里有两个思路通用做法用mysqldump导出全库 SQL再到服务器通过命令行导入。适合一次性全量迁移。增量同步如果你的系统已经在生产上跑了希望把新产生的订单流水实时同步到另一台只读从库可以配置 MySQL 的 binlog 同步或者用 Canal、Maxwell 这样的工具监听 binlog 变更。这个场景在毕设里不会遇到但在真实业务中非常常见了解原理能加分。另外数据库同步/备份的意识要建立起来。我见过不止一个同学开发到一半把本地库删了结果几个月的心血全没了的悲剧。建议在application.yml里配置 MySQL 的定时备份任务比如每天凌晨2点通过 mysqldump 全量备份保留最近7天的备份文件。一行 cron 表达式救回半条命。6. 常见问题排查与避坑速查表6.1 SpringBoot 启动与依赖相关的典型问题问题1启动时端口被占用后端项目默认跑 8080 端口如果你本地有东西占了这个端口启动直接报Port 8080 was already in use。排查方法netstat -ano | findstr 8080 # Windows lsof -i:8080 # Mac/Linux找到占用的 PID 干掉进程或者在application.yml里改一个端口。我们项目最终部署时统一跑 8080本地开发时建议一人一个端口避免多开项目冲突。问题2SpringBoot 版本过高导致依赖不兼容如果你用 SpringBoot 3.x但项目的依赖还是 2.x 时代写的比如某些 MyBatis-Plus 版本会出现创建 Bean 失败、自动配置类找不到的问题。解决办法是先统一版本。推荐 SpringBoot 2.7.18 MyBatis-Plus 3.5.3.1 JDK 8这三个版本组合是我实测最稳的组合。问题3Bean 循环依赖如果你写代码时不小心让两个 Service 互相 New 对方Spring 容器启动时会报循环依赖的错误。不要试图在字段上加Lazy绕过它而是重构设计把公共服务拆成独立的 Util 或者第三个 Service。6.2 小程序端接口联调失败的高频原因问题1域名校验失败报错信息类似request:fail url not in domain list。解决方法按优先级排列开发阶段开发者工具勾选不校验合法域名真机调试预览时同样勾选正式上线在小程序管理后台配置 request / uploadFile 合法域名并且域名必须支持 HTTPS。这一步必须在正式版本发布前完成因为预览/真机阶段可以绕过但审核和线上版本不允许。问题2接口返回 JSON 解析失败多数情况是后端响应里带了大字段或者非 UTF-8 编码。SpringBoot 默认是 UTF-8 没问题要检查数据库中表的 charset 是否 utf8mb4。另外application.yml里要加一句server: servlet: encoding: force: true否则不同平台的默认编码可能不同中文会乱码。问题3小程序包里图片加载不出来后端返回的图片地址如果是http://localhost:8080/xxx.jpg小程序真机无法访问因为 localhost 指向的是手机自己。另外就是图片存储服务MinIO的访问地址必须是公网可访问的。所以本地调试时图片地址建议用当前请求的域名动态拼接而不是硬编码。6.3 缓存、时区与并发扣减的隐藏问题问题1缓存和数据库不一致如果更新了课程信息比如改了价格但 Redis 里缓存的是旧数据用户看到的还是原价。解决办法我在 3.2 提过更新数据库时同步删除缓存即可。这里要注意删除缓存的操作和更新数据库操作之间可能有时间差极端情况下并发请求会读到旧值然后写回缓存。更稳妥的做法是延迟双删先删除缓存再更新数据库等几百毫秒后再删一次缓存。问题2时区问题导致排课时间差8小时MySQL 连接串里必须加serverTimezoneAsia/Shanghai否则默认时区可能跟你的服务器不一致排课时间会相差 8 小时。这是后端项目里最常见的隐藏故障因为本地开发时电脑时区就是北京时区看不出毛病一部署到海外区服的云服务器就现出原形。问题3签到并发导致课时多扣同一个孩子同时被老师和家长扫码签到如果两端同时发起请求剩余课时可能被扣两次。解决思路是给签到增加唯一约束user_id schedule_id date数据库层面保证一条记录只能签一次。这比在代码里加synchronized或者加 Redis 锁更可靠因为数据库唯一索引是最后的防线。7. 从输出成果到答辩展示的实用建议如果这是你的课程设计/毕业设计光把系统跑通还不够答辩时如何展示和讲解才是决定分数高低的关键。我的建议是这样的结构先讲业务场景用一分钟说清楚你现在面对的行业痛点家长不知道孩子状态、机构统计繁琐让评委明白你不是在做玩具项目而是在解决真问题。再讲技术方案重点讲清楚系统架构如何通过 Redis 缓存提升接口性能、如何通过 JWT 解决无状态鉴权、如何用唯一索引保证并发安全这些都是有分量的技术亮点。现场演示走主链路用户注册登录 → 首页浏览课程 → 购买课时包 → 预约报名 → 老师端签到 → 家长端查看剩余课时。这条链路走完评委对整个系统的业务闭环就有直观感受了。演示一个运维亮点比如现场把 Redis 停了看系统降级表现或者展示数据库表结构设计和索引优化前的执行计划对比。这部分不用太深但能证明你真的理解这套系统。最后主动抛出你遇到的坑和解决过程踩坑经历是区分背代码和真做过的最好证据。我家访过很多项目最打动评委的往往不是你功能多全而是你能说清楚某个功能为什么要这样设计某个 bug 是怎么一步步排查出来的。另外演示的时候别只开 IDEA 的工程视图要把doc.html接口文档页面和数据库表 open 在旁边评委问到哪个环节就能立刻切过去展示。数据库的 E-R 图如果在文档里有务必打印出来带到现场这个比嘴上解说一百遍都管用。我自己做完这套系统后最大的感受是技术栈本身不复杂难的是把所有环节串起来后还要保证数据一致性和用户体验。你写完 CRUD 只是拿到了基础分把缓存、幂等、并发控制、状态机这些细节打磨到位才是真正拉开差距的地方。最后分享一个个人习惯每次改完代码先本地把全链路测一遍注册 → 下单 → 签到 → 查课时再提交到 Git。别小看这个动作它能省下你临近答辩时排查环境问题的无数时间。这种系统最怕的不是功能写不出来而是最后三天发现环境起不来——那种感觉我希望你永远别遇到。