Pinxian Li毕设选“健身房预约平台”的人特别多，但真能把这个题做扎实的人确实不多。大多数人最后交上去的东西，不过是在微信小程序里把课程列表来回切，预约和退约的边界条件、用户快速连点造成的重复预约、教练同一时段被约满、登录态过期后用户还在操作……这些实际问题一个都没接住。我这次的做法是 SpringBoot 2.7 做后端服务，微信小程序做 C 端用户入口，再配一个 PC 管理后台，把登录、预约、取消、核销、统计这一整条闭环完整跑通，代码和文档都整理成了可以直接对标毕业设计的交付形态。
选题逻辑其实很直接：这个系统比图书管理多一层“资源冲突”，比电商少一套复杂的商品模型和支付流程，业务量级刚好卡在毕设该有的难度区间。不管你是打算直接复用这套前后端代码，还是只想借这个思路自己复刻一套，核心值得写进博客和说明文档的，基本都集中在版本适配、数据库防重、登录态维护和上线调试这几个地方。下面我把整个项目的落地过程拆开讲。
1. 先想清楚：这个系统要服务三类人，不是一张课程表
1.1 会员、教练、管理员各看什么数据
很多同学拿到这个题第一反应是“做个课程表”，这是最容易跑偏的地方。健身房预约平台的本质不是展示课程，是管理“稀缺资源”：一个时段里教练只有一个，场地只有这么多，会员能不能约上，完全取决于资源被谁、在什么时间、以什么状态占用。
会员打开小程序，关心的是今天门店有哪些课程可以约、对应教练是谁、还能不能约上。教练打开系统，关心的是某天某时段的课有几个人预约，有没有人临时取消，今天的核销情况怎么样。管理员打开 PC 后台，关心的则是会员数据、教练课时、场地维护、预约到场率。三个角色背后对应的是三种完全不同的数据视图：会员看可用性，教练看排期与人数，管理员看运营和配置。
需求分析阶段能把这三种视角聊清楚，数据库表设计就不会太离谱。而我实际做的时候，把会员和教练都归到了 User 表体系里，用角色字段区分，但教练有额外的授课小时数和擅长项目字段；管理员不参与业务预约，只通过后台接口操作，所以没有单独建管理员登录页面，而是直接给 PC 端配了独立的账号体系。
1.2 功能优先级：先跑通“一个名额的完整旅程”
功能不是越多越好，我给自己排了三期优先级。第一期先做微信登录、课程和时段展示、提交预约、我的预约列表、取消预约。第二期做管理后台的场馆、场地、教练、课程维护，以及预约核销功能。第三期再做预约统计报表、超时未到标记、消息通知这类加分项。
我特别建议把“取消预约”放进第一期，因为它是预约状态机里最容易出错的一条路径：预约成功变成已预约状态，取消后回到已取消，课程开始后变成已完成或未到。状态一旦乱，统计数据必然跟着错。很多毕设最后是在这个环节被打回重写的，因为演示时老师一定会问“如果会员约了又不来怎么办”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型与版本匹配：SpringBoot 为什么不能无脑选最新
2.1 前后端技术栈确定了什么
后端我选的是 SpringBoot 2.7.18，搭配 MyBatis-Plus 3.5.3.1、MySQL 8.0、JWT 做登录令牌。小程序端是原生微信小程序，没有上 uniapp 或 Taro，因为原生小程序对微信登录、支付、订阅消息的原生 API 支持最直接，调试起来也少一层中间转换。PC 管理后台用的 Vue 2 + ElementUI，单独跑一个前端服务，通过 API 和后端通信。
这个技术栈不是什么惊天动地的创新，但它有一个实打实的好处：资料多、兼容性好、遇到问题一搜就有解决方案。毕设项目的目标不是验证最新框架，是在有限时间内把所有功能稳定跑通、能答辩、能部署。
2.2 Spring Boot 3.x 和 2.7 到底差在哪
我见过不少同学一上来直接建 Spring Boot 3.2 项目，然后卡在启动报错上。Spring Boot 3 要求 JDK 17 起步，很多学校的实验环境和部署文档还停留在 JDK 8。如果你在 JDK 8 环境里强行用 Spring Boot 3，连项目都跑不起来。另外，MyBatis-Plus 对 Spring Boot 3 需要单独引入 mybatis-plus-spring-boot3-starter，而不是原来的 mybatis-plus-boot-starter，这个不起眼的区别能卡掉一大半新手。
Spring Boot 2.7 是 2.x 时代的最后一个维护版本，既支持 JDK 8，又保留了大家熟悉的自动装配方式，资料参考量最多。它对一个小型预约平台来说，性能完全够用。选型时我也考虑过要不要上 Redis 做缓存，但考虑到预约平台的数据量级不大，默认先把读操作走 MySQL，缓存只是预留了接口，没有强行引入，避免增加部署复杂度。
2.3 核心依赖坐标，直接抄
我用的是 Maven 管理后端依赖，pom.xml 里最关键的几个依赖大概是这样的：
xml复制<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.7.18</version>
<relativePath/>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-validation</artifactId>
</dependency>
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-boot-starter</artifactId>
<version>3.5.3.1</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.33</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt-api</artifactId>
<version>0.11.5</version>
</dependency>
</dependencies>
这里有个小细节：mysql-connector-java 8.0.33 在 Spring Boot 2.7 里可以直接用官网指定的版本号，但驱动类名要写成 com.mysql.cj.jdbc.Driver，而不是老的 com.mysql.jdbc.Driver。配置连接串时还要显式带上 useSSL=false 和 serverTimezone=Asia/Shanghai，否则 MySQL 8 会在时区和 SSL 校验上给你制造惊喜。
3. 数据库设计：预约不冲突的关键在表结构
3.1 五张核心表和它们的分工
整个系统的核心表我控制在五张：用户表 user、教练表 coach、课程表 course、排课表 course_schedule、预约记录表 reservation。另外还有场地表 venue，因为同一个排课时段必须绑定具体场地，否则会出现教练和场地两边都冲突的情况。
排课表 course_schedule 是最重要的一张表，我一开始就给它留了这些字段：id、course_id、coach_id、venue_id、schedule_date、start_time、end_time、capacity、booked_count、status。这里要特别强调，我存的是 schedule_date 加 start_time/end_time，而不是只存一个“星期几”。因为同一个课程每周会重复出现，如果只存星期几，就没办法区分两周前和下周的同一节课。正确的做法是管理后台生成某一天的排课记录时，把具体的年月日写进 schedule_date，前端列表也按日期去查。
预约记录表 reservation 则要记录：id、user_id、schedule_id、reservation_status、reservation_time、cancel_time、checkin_time。reservation_status 我用了数字枚举，0 表示已取消，1 表示已预约，2 表示已完成，3 表示未到。这个状态字段是后面所有业务判断的基础。
3.2 用唯一约束治“重复预约”这个老大难
很多人会把防重复预约写成“先查询、再判断、最后插入”的三步逻辑，这个逻辑在单用户串行操作时没问题，但用户如果在预约页面快速点两次提交，两个请求几乎同时到达后端，两个查询都读到“还有名额”，两个插入都成功，就产生了重复预约。
我给出的解法分两层。第一层是唯一的业务约束：在 reservation 表上建一个联合唯一索引，包含 user_id 和 schedule_id。这样同一用户同一排课记录只能存在一条预约记录，数据库层面直接拦截重复插入。第二层是事务里对排课记录加行锁：在创建预约时，先对 course_schedule 表执行 select ... for update，锁定该条排课记录，再统计已预约人数判断是否满员，最后插入 reservation 并更新 booked_count。代码逻辑大概是：
java复制@Transactional
public void createReservation(Long userId, Long scheduleId) {
CourseSchedule schedule = courseScheduleMapper.selectByIdForUpdate(scheduleId);
if (schedule == null || schedule.getStatus() == 0) {
throw new BusinessException("当前排课不存在或已下架");
}
Long bookedCount = reservationMapper.countByScheduleId(scheduleId);
if (bookedCount >= schedule.getCapacity()) {
throw new BusinessException("该时段名额已满");
}
Long exists = reservationMapper.countByUserAndSchedule(userId, scheduleId);
if (exists > 0) {
throw new BusinessException("你已预约过该时段，请勿重复预约");
}
Reservation reservation = new Reservation();
reservation.setUserId(userId);
reservation.setScheduleId(scheduleId);
reservation.setReservationStatus(1);
reservation.setReservationTime(new Date());
reservationMapper.insert(reservation);
}
我在 explain 里确认过，selectByIdForUpdate 走的 id 主键索引，所以锁的是一行记录，不会因为锁表把整个系统的并发能力拖垮。毕设级别的并发量用这个方案足够，如果以后想扩展分布式场景，再考虑引入 Redisson 分布式锁，把锁的粒度从数据库行锁升级到 Redis 锁。
3.3 不要在前端写死“每周重复”
还有一个坑，就是不要为了省事直接让前端生成七天可预约的假数据。正确的方式是管理后台在每天零点前生成第二天的排课记录，或者手动选择某课程并设置一个日期范围，由后端循环生成多天的 course_schedule 记录。我实现里加了一个简单的生成接口，传入课程 id、开始日期、结束日期、每日的课时时间段，后端自动往 course_schedule 表里插入数据，并用唯一索引约束 course_id + schedule_date + start_time 来防止重复生成。
这个设计还有一个隐藏优势：它能自然支持“今天暂停营业”这种场景。管理员只需要把某天的排课记录状态置为 0，前端就不会再把这条排课暴露给用户，不需要额外写复杂的过滤规则。
4. 后端核心接口实现：微信登录、预约防重、取消与过期释放
4.1 wx.login 拿到 code 之后，后端做了什么
小程序端通过 wx.login 拿到一个临时 code，这个 code 只能使用一次，有效期只有五分钟。后端拿到 code 之后，需要拿着 code 加上小程序的 appid 和 secret，去调微信的服务端接口 code2Session，换回 openid、session_key 信息。
这里有一个毕设生经常踩的坑：微信登录接口的 appid 和 secret 必须和你小程序实际使用的 appid 一一对应。如果你在小程序开发者工具里用的是测试号，而后端配置的是正式 appid，或者反过来，code2Session 就会返回错误码。我在实际开发中把 appid 和 secret 统一放进了 application.yml，并且通过配置类注入，而不是硬编码在 Controller 里。
拿到 openid 之后，我先把 openid 去 user 表查询，查不到就自动创建一条新用户记录，昵称给一个默认值“微信用户”。然后后端签一个 JWT 返回给小程序，后续所有需要身份识别的接口，前端都在请求头里带 Authorization: Bearer token，后端通过拦截器解析 token 拿到 userId。选 JWT 而不是 redis session 的原因很简单：小程序端是纯 API 调用的场景，没有 Cookie 机制，JWT 天然无状态，后端重启也不影响已登录用户。
4.2 预约接口的完整判断链路
预约接口是系统中最核心的接口，除了上面说的防重复预约，还要处理几个边界条件。第一个是预约时间窗口：课程开始前 30 分钟不允许预约，防止用户约了立刻就要上课的情况。第二个是提前取消时间：我设定开课前 2 小时允许用户自己取消，开课前 2 小时以内要取消就得联系管理员在后台操作。第三个是用户每天的预约上限，防止一个人把当天所有时段都占满。
这些判断我全部放在 Service 层，用统一的 BusinessException 抛出错误信息，由全局异常处理器捕获后返回给前端。比如预约时间窗口的判断逻辑是这样：
java复制if (schedule.getScheduleDate().isBefore(LocalDate.now())) {
throw new BusinessException("不能预约过去的排课");
}
if (LocalDateTime.of(schedule.getScheduleDate(), schedule.getStartTime())
.isBefore(LocalDateTime.now().plusMinutes(30))) {
throw new BusinessException("课程开始前30分钟内不允许预约");
}
这样前端只需要根据接口返回的 code 统一提示，不需要在页面里复制一套同样的判断逻辑，减少前后端不一致的风险。
4.3 定时清理：让“占着名额不付款/不出现”的预约自动释放
很多真实预约平台都有支付超时自动关闭订单的逻辑，我的实现里简化了但保留了类似机制：如果用户预约后 15 分钟内没有完成支付或确认操作，就用一个定时任务把状态为“待确认”的预约置为已取消，并同步把 booked_count 减回去。
这个定时任务我用的是 Spring 自带的 @Scheduled，配置了 fixedDelay = 60000，也就是每分钟扫描一次。虽然这个方案在分布式部署下会有重复执行的问题，但毕设项目部署在单台服务器上完全够用，而且代码比引入 xxl-job 之类的外部调度中心简单太多。我在说明文档里也额外写了扩展方向：如果以后要部署多实例，需要给定时任务加分布式锁或者改用消息队列延时消息。
另外一个定时任务是每天晚上十点，把当天所有状态还是“已预约”的排课记录更新成“已完成”，同时给未核销的预约打上“未到”标记。这里的关键是不要只更新 reservation 的状态，还要同步更新统计表里的到场率、爽约率，不然管理后台的报表会失真。
5. 小程序前端完整链路：登录授权、请求封装、预约状态同步
5.1 登录链路：别在启动时无脑调 wx.login
小程序端第一个要解决的就是登录态。很多同学习惯在 app.js 的 onLaunch 里直接调 wx.login，然后拿 code 去换 token，但这样有两个问题：一是 onLaunch 里的异步请求还没有完成时，首页的数据请求已经发出去了，导致首页拿不到 token；二是每次冷启动都换一个新的 token，浪费接口请求。
我的做法是写一个 ensureLogin 方法，先检查 storage 里的 token 是否存在且未过期，如果存在就直接用，如果不存在或者接口返回 401，再发起 wx.login 流程。首页的数据请求统一在 onLoad 里先 await ensureLogin()，再拉取接口数据。代码结构类似：
javascript复制function ensureLogin() {
return new Promise((resolve, reject) => {
const token = wx.getStorageSync('token');
if (token) {
resolve(token);
return;
}
wx.login({
success: (res) => {
request.post('/auth/login', { code: res.code })
.then((data) => {
wx.setStorageSync('token', data.token);
wx.setStorageSync('userInfo', data.userInfo);
resolve(data.token);
})
.catch(reject);
},
fail: reject
});
});
}
这里要提醒新手一句：wx.login 返回的 code 只能使用一次，如果你在请求过程中因为网络等问题重试了同一个 code，后端二次调用 code2Session 会报 code 已被使用。所以重试机制必须放在整个“重新 wx.login 获取新 code”的层面，而不是简单地把同一个请求重发一遍。
5.2 请求封装：状态码统一处理
原生小程序的 wx.request 写起来很啰嗦，我把它封装成了一个 request 方法，统一处理四个东西：请求头的 token 注入、加载提示、HTTP 状态码判断、业务状态码判断。每当后端返回 401 时，自动清除本地 token，并跳转到登录页提示用户重新登录。
这个封装的代码不复杂，但实际使用中帮了大忙，因为小程序页面多、请求多，如果每个页面都单独处理错误提示，代码会膨胀得非常厉害。我现在每个接口调用都是三四行代码，维护成本很低：
javascript复制const api = {
getScheduleList: (params) => request.get('/schedule/list', params),
createReservation: (data) => request.post('/reservation', data),
cancelReservation: (id) => request.put(`/reservation/cancel/${id}`),
};
5.3 预约页与“我的预约”页的状态同步
预约页的核心交互是：用户选择日期，系统加载该日期的排课列表；每个排课卡片显示课程名、教练、时间段、剩余名额；“预约”按钮按剩余名额和预约状态动态禁用。用户提交预约成功后，要立刻把当前卡片的剩余名额减一，同时跳转到我的预约页面，让用户马上看到新生成的预约记录。
我的预约页面则是按状态分 Tab 展示：待上课、已完成、已取消。待上课列表里的每条记录显示预约详情和“取消预约”按钮，取消成功后记录状态立即切换。这里有一个体验优化：我用了小程序的 setData 局部更新，而不是整个列表重新拉取，这样用户在取消后不用看到列表重新加载的 loading 状态，实际操作体验更接近真实的商业小程序。
前端要注意的另一个点是微信在头像昵称获取能力上的调整，现在不能像以前一样直接通过 getUserInfo 拿到用户头像和昵称，必须用户主动填写。所以我的登录流程里注册新用户时只拿 openid，头像昵称放在用户进入“个人中心”时引导填写，避免一进来就弹授权框，降低用户流失率。
6. 部署调试阶段的高频坑：域名校验、登录失败和开发者工具配置
6.1 request 合法域名到底卡在哪
小程序上线之前，在开发者工具里可以勾选“不校验合法域名”，很多人在这个阶段开发得很开心，一到真机预览或提交审核就发现所有接口请求全部失败。原因是微信小程序要求所有网络请求必须走 HTTPS，而且这个域名必须在小程序后台配置到 request 合法域名里，域名还需要完成 ICP 备案。
我部署时的做法是：买一台云服务器，域名解析到服务器 IP，用 Nginx 做 443 端口反转代理到后端 Spring Boot 的 8080 端口，再配好 SSL 证书。整个链路从前端请求 https://api.xxx.com 开始，Nginx 接收请求后转发到本机的 localhost:8080。Spring Boot 本身不需要自己处理 HTTPS 证书，全部交给 Nginx 一层，配置和维护都简单很多。这个方案我在说明文档里写了完整步骤，包括 Nginx 的 server 配置片段。
6.2 “获取微信用户失败”最常见的三种原因
小程序开发时经常看到“获取登录后的微信用户失败”这类错误，我排查下来基本集中在三个原因。
第一个是 appid 配置错误。开发者工具里如果用了测试号，或者从一个项目复制到另一个项目时 appid 没有改，code2Session 就拿不到有效数据。我遇到过 HBuilderX 打开项目后，微信开发者工具里显示的小程序 id 还是上一个项目的，最后发现是 manifest.json 里的 mp-weixin.appid 字段被缓存了，需要检查配置后重新编译。
第二个是 secret 和 appid 不匹配。很多人会把某个小程序的 appid 配在前端，把另一个小程序的 secret 配在后端，这种低级错误非常隐蔽，因为编辑器不报错，只有调接口时才返回错误码。我的建议是写一个简单的启动自检接口，在项目启动时打印当前使用的 appid 后四位，方便核对。
第三个是 code 被重复使用。前面提到过，wx.login 返回的 code 是一次性的，如果前端因为超时重试导致同一份 code 被发送多次，后端第二次调用 code2Session 就会报错。解决方法是前端做好登录态管理，code 只在 ensureLogin 流程中用一次，不要拿到页面的其他逻辑里复用。
6.3 用开发者工具调试器和控制台定位问题
小程序端的调试不用搞得很复杂，微信开发者工具自带的 Network 面板、Console 面板、Storage 面板已经够用。我排查问题时最常用的路径是：先在 Console 里看有没有报错，再切到 Network 面板看请求的完整请求头、请求体和响应体，重点确认 Authorization 头有没有带上、响应里的 code 是多少。
真机调试和开发者工具之间有一个差异值得提：真机预览时必须使用已配置好的 HTTPS 域名，本地 localhost 是访问不到的。所以开发阶段我直接把后端接口地址做成了环境变量，开发环境指向局域网 IP，预览环境指向线上域名，切换时只需要改一个配置文件。这个小细节能省下大量来回换代码的时间。
7. 交付物整理和答辩演示：别让代码成为唯一的表达
7.1 目录结构怎么组织才算清晰
毕设要交的东西不只是能跑的代码，还有说明文档和演示。我的项目目录是这样组织的：根目录下有 backend 和 miniprogram 两个文件夹，backend 里按 controller、service、mapper、entity、config 分包，miniprogram 下按 pages 和 utils 组织。另外单开一个 docs 目录，里面放数据库脚本 init.sql、接口文档.md、部署说明.md。
后端分包的核心原则是让答辩老师一眼看出分层：Controller 只做参数接收和响应包装，Service 只做业务逻辑，Mapper 只做数据库操作。很多同学喜欢把业务逻辑全写在 Controller 里，代码行数少但极其不利于答辩，老师问“你的事务加在哪一层”时基本答不上来。
7.2 演示数据和演示流程怎么准备
答辩前我一定要准备好一套完整的演示数据，包括三个会员账号、五个教练、六个课程、未来三天的排课记录。演示流程按业务路径走：先演示学员端微信登录，查看课程并预约，演示“名额已满”的情况，再演示取消预约；然后切到管理后台，新增一个课程排课，查看今天的预约列表并核销；最后演示统计报表，看今天的预约人数和到场率。
预约的并发场景尤其要演示。我会提前预约到只剩一个名额的状态，然后在页面上连续快速点击两次预约按钮，展示系统如何拦截第二次重复预约。这个演示比讲一百行代码都有说服力，因为老师知道这是真实业务里最容易出现的 bug。
7.3 论文和说明文档里最值得写的三个点
文档写作上，我建议把重心放在三块：第一块是需求分析和 ER 图设计，尤其是预约状态机的定义，配一张状态转换说明；第二块是防重复预约的数据库唯一索引加行锁方案，突出你考虑了并发场景，而不是简单的 CRUD 说明；第三块是部署文档里的域名配置和 Nginx 反向代理，这是最容易让项目从“本机运行”升级成“可上线状态”的关键一步。
调试定制的部分我单独做了一个 QA 文档，把自己遇到的 Spring Boot 版本问题、小程序域名校验问题、微信登录 code 失效问题全部记录成“问题描述-排查过程-解决方案”三段式结构，这种文档不仅对答辩有直接帮助，对你以后找工作写博客、做项目复盘也是特别好的素材积累。
最后再分享一个我在实际调试中的体会：做这种全栈毕设项目，最大的敌人不是技术难度，而是“版本环境不一致”和“前端后端各说各话”。把接口字段在文档里写清楚、把环境配置在启动说明里写清楚、把每个状态码的含义提前定好，项目推进速度会比闷头写代码快得多。后面如果你还想继续扩展，这个预约平台可以加会员卡次卡扣减、签到积分、教练课程评价，甚至接入微信订阅消息做开课提醒，底层这套登录和预约核心逻辑都不需要动。