这个选题我前后带过不少同学做过今天聊点实在的。先亮个底基于微信小程序的健身房预约系统在整个课设和毕设题库里属于性价比很高的一类项目麻雀虽小但五脏俱全——前端要处理小程序登录、页面交互、状态管理后端要处理鉴权、预约业务、冲突校验、支付回调部署层面还要搞定HTTPS域名校验。很多同学卡在中间某个环节就放弃了其实把链路理顺之后这个系统一周左右就能跑通全流程。先说结论这类项目适合三种人参考——准备做课程设计或毕业设计的在校生、想快速掌握前后端联调流程的初级开发者、以及打算把健身房约课做成小产品的创业型选手。它的核心价值在于帮你理清一套完整业务闭环怎么做而不是某一个单一技术点。1. 先想清楚整体骨架技术选型与工程结构1.1 为什么微信小程序当客户端最合适健身房预约这个场景用户核心动作是打开手机看课表、选时段、预约、到店核销。如果做原生App下载成本太高用户大概率不会为了约一节操课去装一个40MB的安装包如果做H5入口太浅很难收到订阅消息提醒而且微信内打开H5的体验确实一般。小程序刚好卡在中间。它不用安装扫码或者搜索就能打开微信生态内可以直接拿到用户身份标识还能发模板消息提醒用户上课。对健身房这种高频但轻量的预约需求来说入口足够短用完即走非常契合。这里有个细节很多人没想到小程序包的体积限制是2MB主包最好控制在1.5MB以内。如果你用原生小程序开发能压的空间不大如果用一些重型的UI框架很容易触碰包体红线。我后面细说代码的时候会给大家展示怎么精简。1.2 后端框架怎么挑我为什么选了Spring Boot这个项目的后端方案一般有几种Spring Boot、Node.js的Express或者Nest、Python的Flask或Django。如果是为了毕业设计我推荐Spring Boot如果是为了快速上线一个小工具我推荐Nest或者Express。为什么Spring Boot生态成熟MyBatis-Plus、Spring Security、Redis客户端这些集成起来都是现成的社区案例多出问题一搜就有答案。对于学生项目来说答辩的时候老师问到“你怎么处理并发冲突”用Spring Boot加Redis做分布式锁是一个很扎实的亮点。而Node的话胜在前后端都写JavaScript语法心智负担低但事务处理和定时任务这块要自己拼的东西稍微多一点。我的建议是你的课程里哪门语言学得最熟就选哪个框架。技术选型不是越新越好而是你兜底的能力最强。项目能跑通、逻辑能讲清楚比用什么框架重要一百倍。还有一个决策点是用不用前后端分离。这个项目强烈建议前后端分离小程序端是独立的工程后端只出JSON接口。这样做的好处是调试的时候你可以在微信开发者工具里直接改接口地址指向本地也可以在浏览器里用Postman单独测试接口两边互不干扰。1.3 工程目录怎么拆前后端怎么联调我通常建议把项目拆成三个目录miniprogram小程序端、server后端服务、docs文档和SQL脚本。有些同学喜欢把小程序端直接塞在项目根目录下后端又单独一个仓库这样不是不行但如果要交源码加文档还是建议放在一个总目录下方便老师直接解压就能看。后端的包结构建议这样分层com.example.gym ├── controller // 接口层只做参数接收和结果返回 ├── service // 业务层预约校验、状态流转都在这 ├── mapper // 数据访问层 ├── entity // 数据库实体 ├── config // 全局配置比如拦截器、跨域、Redis配置 ├── common // 公共返回体、异常处理、工具类 └── task // 定时任务例如超时自动取消小程序端目录用原生写法的话就是标准的pages、components、utils、api四个核心目录。一个容易被忽略的细节是把所有的接口请求地址封装到一个config.js里调试的时候切换开发环境和线上环境只需要改一个变量。前后端联调的时候建议统一用Postman或者更轻量的Apifox把每个接口的入参、出参、鉴权方式都测一遍再开始写页面。我在实际给学员辅导时经常发现一种情况——“页面写完了接口联调时才发现后端返回的字段名对不上”。所以在动手页面之前先把接口契约定死尤其是这些字段code业务状态码、message提示信息、data真实数据。2. 核心业务拆解把预约这件事变成数据模型2.1 用户、教练、课程、场地四张主表怎么设计健身预约系统最核心的功能是“在某个时间段、某个场地、某个教练的某节课可以被某个用户预约”。所以主表至少要有四张用户表、教练表、课程表包含场地信息、预约记录表。有些系统还会加一张场地表这个看你的场地是否需要多人同时预约如果是一对一的私教课课程表里直接放场地字段就够了。用户表user关键字段字段名类型说明idbigint主键openidvarchar(64)微信唯一标识nicknamevarchar(50)昵称phonevarchar(20)手机号可用于接收提醒roletinyint0为普通用户1为管理员2为教练statustinyint0正常1禁用create_timedatetime注册时间课程表course关键字段字段名类型说明idbigint主键coach_idbigint教练IDnamevarchar(100)课程名称比如“燃脂操”“动感单车”typetinyint课程类型start_timedatetime开始时间end_timedatetime结束时间max_countint最大预约人数booked_countint已预约人数statustinyint状态可预约、已约满、已取消、已结束locationvarchar(100)场地位置预约记录表booking_record关键字段字段名类型说明idbigint主键user_idbigint用户IDcourse_idbigint课程IDbook_timedatetime预约时间statustinyint0已预约1已取消2已核销3已过期cancel_timedatetime取消时间checkin_timedatetime核销时间这三张表设计好之后整个系统的骨架就立住了。2.2 预约规则与状态机如何做到不超卖、不冲突预约系统比普通的增删改查复杂在两个字冲突。用户A和用户B同时预约最后一节课系统只能让一个人成功这是并发冲突用户已经预约了周三晚上7点的课又想约周三晚上8点的课但两节课时间挨着这是时间冲突。处理并发冲突最简单可靠的方式不是在后端代码里判断而是在数据库层面做约束。核心SQL是这样的UPDATE course SET booked_count booked_count 1 WHERE id #{courseId} AND booked_count max_count AND status 1这条语句执行后通过受影响行数判断是否预约成功。如果行数为0说明课程已满或者状态不对直接返回“预约失败”。这样即使100个人同时请求数据库的行锁也会保证只有一个请求能成功更新booked_count。这就是我把“先查再改”改成“条件更新”的意义所在——避免了典型的超卖问题。但光限制总人数还不够还要防止同一个用户重复预约同一节课。这时候在预约记录表上加一个唯一索引就行ALTER TABLE booking_record ADD UNIQUE KEY uk_user_course (user_id, course_id);插数据的时候如果违反唯一约束数据库会直接报错这也是最底层的兜底。时间冲突的判断逻辑相对独立我放在Service层处理// 查询该用户所有状态为“已预约”的课程检查时间是否重叠 ListCourse bookedCourses courseMapper.selectBookedByUserId(userId); for (Course item : bookedCourses) { boolean conflict !(newCourse.getEndTime().compareTo(item.getStartTime()) 0 || newCourse.getStartTime().compareTo(item.getEndTime()) 0); if (conflict) { throw new BizException(与已有课程时间冲突); } }2.3 管理端和用户端权限边界在很多课程设计项目里权限管理做得非常敷衍菜单虽然写着“管理员”但后端接口根本不过鉴权任何人都能调用。这种问题在答辩的时候被问两句就露馅了。我建议用一个最简单的拦截器做权限控制。后端定义一个RequireRole注解标注在Controller方法上拦截器里从Token中解析出用户角色比对通过才放行。这样用户的预约操作和管理员的管理操作就有了明确的边界用户端查看课程列表、预约课程、取消预约、查看我的预约、核销自己的预约码。管理端发布课程、修改课程、查看所有预约记录、手动核销、用户管理、数据统计。管理员发布课程的接口在Controller里标记了RequireRole(role ADMIN)普通用户就算知道接口路径调用也会被拦截。3. 关键链路实操从点开小程序到完成预约3.1 微信登录与手机号绑定很多初学同学会觉得微信登录很神秘其实流程不复杂小程序端调用wx.login()拿到一个临时code传给后端后端拿着code去微信的接口换openid和session_key再拿openid去数据库查用户查不到就自动注册最后签发一个自定义Token返回给小程序。核心的Java代码是这样PostMapping(/login) public Result login(RequestBody LoginDTO dto) { String url https://api.weixin.qq.com/sns/jscode2session?appid appId secret appSecret js_code dto.getCode() grant_typeauthorization_code; String result restTemplate.getForObject(url, String.class); JSONObject json JSON.parseObject(result); String openid json.getString(openid); User user userMapper.selectByOpenid(openid); if (user null) { user User.builder().openid(openid).role(0).status(0).build(); userMapper.insert(user); } String token JwtUtil.createToken(user.getId(), user.getRole()); return Result.success(token); }手机号绑定是另一道流程。小程序端用button的open-typegetPhoneNumber拿到手机号加密数据后端需要调用微信接口解密拿到真实手机号后更新到用户表。这里有一个常见的坑个人主体的小程序没有权限调用获取手机号接口只有企业主体小程序才行。做课设模拟的时候可以用一个“请输入手机号”的普通表单替代功能效果完全一样。3.2 预约、取消、核销的后端接口设计预约接口是整个系统的核心我贴一段完整的Service层逻辑大家可以直接参考Transactional(rollbackFor Exception.class) public Result book(Long courseId, Long userId) { Course course courseMapper.selectById(courseId); if (course null) { throw new BizException(课程不存在); } if (course.getStatus() ! 1) { throw new BizException(课程当前不可预约); } if (course.getStartTime().before(new Date())) { throw new BizException(课程已开始无法预约); } // 条件更新防止超卖 int rows courseMapper.increaseBookedCount(courseId); if (rows 0) { throw new BizException(课程已约满手慢无); } // 插入预约记录唯一索引兜底 BookingRecord record new BookingRecord(); record.setUserId(userId); record.setCourseId(courseId); record.setBookTime(new Date()); record.setStatus(0); try { bookingRecordMapper.insert(record); } catch (DuplicateKeyException e) { throw new BizException(您已预约过该课程); } return Result.success(); }取消预约的逻辑和预约对称要注意的是取消之后要把booked_count减回去或者用另一种方案预约时先扣减取消时再加回去。这两种方案在并发场景下都行得通我选的是先扣减因为这样能最大程度保证“已约人数”不超过“最大人数”。核销功能是给健身房前台用的。用户到店后展示一个预约码我建议直接用课程ID加预约ID做个简单的二维码前台扫一下验证有效性后端把status改为2完成核销。二维码生成可以用现成库后端生成后base64返回给小程序前端直接用image标签渲染。3.3 时段锁定与并发控制有人会问如果课程表里没有max_count只有一块场地怎么防止两个人同时订到同一个场地这就是“时段锁定”的问题。方案有两种悲观锁和乐观锁。乐观锁就是在course表加一个version字段更新的时候带上WHERE version #{oldVersion}更新成功再set version version 1。悲观锁就是查询时用SELECT ... FOR UPDATE把行锁住再操作。对于健身房预约这种场景我推荐乐观锁加条件更新组合性能更高也不容易死锁。如果预约的人数上限很大比如操课100人一节锁住一整行其实没必要条件更新已经足够解决了。只有像会议室预约这种一对一场景才需要细粒度的时间段锁表。还有一个很容易被忽视的地方用户取消预约之后释放出来的名额如何立即生效。这里有一个边界条件如果用户取消的同时有另一个人正在预约可能发生超卖。解决方式仍然是用数据库条件更新取消时把booked_count减回去预约时先检查booked_count max_count两者在同一行记录上操作数据库的锁会保证最终一致。3.4 消息通知与过期回收用户预约成功后最好能在开场前收到提醒。这块的实现方式是利用微信小程序的订阅消息。用户预约接口里顺便请求订阅消息授权后端在开场前半小时通过定时任务调用微信接口下发提醒。后端定时任务可以用Spring自带的ScheduledScheduled(fixedDelay 60000) public void sendRemind() { ListBookingRecord records bookingRecordMapper.selectNeedRemind(); for (BookingRecord record : records) { // 组装模板消息并调用微信接口 wechatService.sendSubscribeMessage(record.getOpenid(), record.getCourseName()); } }还有一个不可忽视的规则预约后超过某个时间未到场或者课程开始后仍未核销记录要自动置为“过期”。这个也是定时任务扫描处理把status从0改成3同时把booked_count减回去让名额释放给其他用户。我用到的定时任务一般每分钟扫描一次把“已结束并且还没核销”的预约批量更新为过期状态。这样即使用户忘了取消课程结束之后名额也会被释放不会永远占着。4. 调试实录真机联调与线上部署避坑指南4.1 开发者工具联调时常见报错微信开发者工具里有几个万年不变的坑几乎每个同学都会踩第一域名校验。开发环境下可以在开发者工具里勾选“不校验合法域名”但一旦预览或上线所有请求的域名必须是HTTPS且在后台配置过白名单。很多同学本地跑得好好的一用手机预览就白屏一查全是这个原因。第二wx.request的最大并发限制。小程序用request请求时如果页面同时在加载多个接口很容易出现部分请求pending。解决方式是控制页面的并发请求数或者用封装好的请求库统一管理队列。我在项目里写了一个简单版的请求管理器限制同一时间的请求数量不超过6个。第三setData大数据量问题。课程列表一次性返回几十条数据直接把整个数组塞进setData里数据量一大页面就卡顿。后端接口要支持分页前端用onReachBottom做触底加载每次只加载20条体验会好很多。4.2 数据库并发问题和时间边界调试并发问题光靠开发环境单机模拟很难测出来。我建议用一个简单的Jmeter或者Postman的Runner功能并发跑20个预约请求看有没有超卖或者重复预约。实测下来只要用了前面说的条件更新加唯一索引基本不会出问题。时间边界问题也很典型。有些同学用new Date()直接比较前后端时间结果因为服务器时区、数据库时区不一致导致提前一小时显示“课程已开始无法预约”或者反之。统一方案是数据库连接串里加上serverTimezoneAsia/Shanghai后端存时间统一用LocalDateTime或DateTime类型前后端传输统一用时间戳或yyyy-MM-dd HH:mm:ss格式的字符串避免任何时区偏移。另外判断“能否预约”的时候不能只看预约的那一刹那还要考虑边界条件。规则一般是开课前30分钟之内不允许取消开课前1小时之内不开放预约具体按业务需求定课程开始后不允许预约。这些规则要固定在Service层统一判断不能在页面层做完判断就不管了因为接口是可以被直接调用的。4.3 部署到服务器需要处理域名与HTTPS校验整个项目走到部署环节最容易翻车的就是HTTPS。小程序要求所有请求域名必须是HTTPS而且证书必须有效。如果你是用某云服务器部署流程大概是买一个域名备案如果服务器在国内。在云厂商的证书管理里申请免费SSL证书下载证书文件。Nginx里配置证书和反向代理把443端口转发到后端服务端口。在小程序后台的“服务器域名”里添加request合法域名。后端代码里配置server.servlet.context-path避免和静态资源路径冲突。如果不想买域名也有一种开发调试用的临时方案在微信开发者工具里直接勾选“不校验合法域名”但真机预览时不生效。所以该配置的域名还得配置。4.4 常见问题速查表现象原因解决办法真机预览请求全部失败域名未配置或证书无效后台添加request合法域名配置HTTPS证书明明课程还有名额却预约失败booked_count和实际记录数不一致写一个定时校对脚本按实际预约记录重算已约人数预约成功后不显示在我的列表状态字段查询条件漏了“已取消”之外的状态查询条件改为status IN (0, 2)用户取消后名额没恢复取消接口没写回booked_count补充booked_count - 1的更新语句时间显示相差8小时时区配置不一致数据库连接串和服务器时区统一配置为东八区小程序包体超过2MB图片太多或组件库太重图片走CDN压缩组件代码分包加载并发下出现重复预约没有唯一索引或没有条件更新加唯一索引改造SQL为条件更新5. 这个项目还能怎么扩展如果你做完基础版本还有精力我建议在以下几个方向挑一两个深挖项目档次会明显提升一是接入微信支付。预约付费课程时可以用小程序支付后端处理下单、回调、退款这个环节能展示你对支付安全的理解比如签名校验、幂等处理、退款状态回写。二是会员卡与次卡扣减。用户购买10次卡每次核销时扣减一次卡剩余次数不足时不允许预约。这个功能涉及次卡表、消费流水表业务逻辑又多了一层非常加分。三是课程签到与教练评价。核销之后用户可以给教练打分、写评价后台能统计每个教练的平均分和课时数展示数据可视化报表。四是排课系统的自动排班。管理员如果每周都靠手动创建几十节课程非常痛苦。可以做批量生成课程模板选择星期几、时间段、重复周数一键生成整月的课表顺便在字段里记录是否节假日。五是过期自动退款。如果用户付费后没有上课且系统判断为“过期”自动触发退款流程并把名额释放。这里注意要先关掉用户主动取消的入口避免重复退款。6. 我的一些体会前后带了不少同学从零搭过类似的系统我发现最后能不能做好往往不取决于代码能力而是前期的规则设计。很多人上手就先写页面写了两天发现预约冲突绕不开又回来改数据表等于白干。我的习惯是先花一个晚上把业务规则一条一条写在纸上比如提前多少分钟不能取消课程开始后未核销是否释放名额同一个用户同一时段能约几节课约满之后是否允许候补每条规则都对应一段代码逻辑和一张表字段。规则定了往后写代码基本就是翻译工作。这个思路放在任何项目里都通用。最后再分享一个小技巧提交文档时把SQL脚本、接口文档、部署文档三个文件单独放在docs目录下命名和代码模块一一对应。表面上是没什么技术含量的小习惯但实际评审的时候会省掉很多“你的项目怎么跑起来”的来回沟通也让整个项目看起来更完整。很多时候差距就是这么一点一点拉开的。