去年我花了三周时间从零把一个“基于微信小程序的健身管理系统”从需求梳理做到了可演示、可答辩的完整状态源码和论文也都配齐了。当时很多同学问我这种带“源码论文说明”的项目到底难不难值不值得做网上下的模板能不能直接用。今天我就把这段实战经历摊开来讲包括技术选型、数据库怎么设计、课程预约的并发坑、Token失效、论文怎么写才能真正和代码对上——全程用做过的真实项目说话。这套系统本质上解决的是健身房里最常见的三个问题会员不知道今天有什么课、不知道教练什么时候有空、办卡之后到底练没练全靠一张纸质记录。于是我把系统拆成了三个角色视角会员端在小程序里完成课程浏览、预约、签到和身体数据记录教练端负责发布课程、维护个人档案、查看名下学员管理端则聚焦在会员卡管理、课程审核和基础数据统计。适合正在做毕设、课程设计或者想用小程序验证一个真实业务闭环的同学参考。1. 项目设计与技术选型1.1 先想清楚健身管理系统到底要解决谁的什么问题很多网上的项目一上来就是“用户管理、课程管理、订单管理”这种大而全的模块堆砌看着功能多实际上每个模块都是死的放几张静态页面就算做完。这是毕设项目最容易被答辩老师拆穿的地方。我踩过这个坑之后重新把需求收敛到一句话——让会员知道今天有什么课上、能不能约上、练得怎么样。围绕这句话用户端只需要五个核心页面首页展示推荐课程、课程列表与详情、预约提交、个人中心、身体指标记录。教练端则需要一个简单的管理视图核心动作是开课、改课、查看约课名单。后台管理反而可以简化放在小程序内用角色区分或者单独做一个极简的Web页面。这样收敛之后整个系统的业务链路就非常清晰教练创建课程 - 会员浏览课程 - 会员提交预约 - 剩余名额扣减 - 上课签到 - 记录训练数据。这条链路做完等于完成了一个完整的小程序业务闭环论文里写“系统实现”章节时也能顺着链路讲清楚而不是东一块西一块。1.2 技术方案怎么选原生小程序还是uni-app后端用什么技术选型是所有人开工前最纠结的点。我的建议是如果目标只是“完成一个微信小程序管理系统”原生小程序 一个轻量后端是最稳的方案没有之一。原生小程序WXML WXSS JS在微信开发者工具里调试最顺畅路由、组件、API 全是原生支持不需要引入额外的框架层。可能有人会说用 uni-app 以后还能编译成 App、H5理论上是这样但实际开发中uni-app 的适配成本往往比想象的高——很多组件属性在微信端和 App 端表现不一致你得花时间精力去读条件编译文档不是划算的事。后端我选的是 Spring Boot MyBatis Plus MySQL。如果只会 PHP 或 Node.js完全可以用 ThinkPHP 或 Express 替代但核心设计思路不变。Spring Boot 的优势在于生态成熟MyBatis Plus 能让单表 CRUD 几乎不用手写 SQLJWT 做小程序登录态的 Token 校验也非常顺手。而且对毕设来说Spring Boot 在论文“技术介绍”章节里可以写的东西够厚评委一眼就能看出你理解了这个技术栈。如果基础比较薄弱听我一句劝不要同时挑战没做过的前端技术 没做过的后端技术。小程序原生 Spring Boot两个方向都学一遍成本可控但如果你还想着前端上 React Native、后端上微服务大概率两周后崩溃。先让系统跑起来再谈炫技。1.3 功能模块拆解一个60分系统和一个90分系统的差距市面上的“健身管理系统”源码很多但大多数只能算60分会员增删改查、课程增删改查、预约增删改查往里填数据。看起来能用但仔细一想和用 Excel 管理有什么区别系统真正的价值在于业务规则。我在这套系统里重点加了四个规则来拉开差距预约课程时校验会员卡是否在有效期内过期不允许预约同一时间段内会员不能预约两门课程每门课程设置名额上限达到上限后禁止继续预约教练不能设置与自己已有排课时间冲突的新课这四个规则做进去之后整篇论文的“系统设计”和“系统测试”章节立刻有了素材。比如测试用例可以写有效期内正常预约、过期卡预约失败、同一时段重复预约失败、课程报满后预约失败。每个用例都有对应的代码逻辑和截图答辩的时候老师问“你的系统怎么保证没有超卖”你就有东西回答了。这也是我在这里特别想强调的不要沉迷于页面数量要沉迷于业务约束。一个页面四个规则远比十个页面四个CRUD更有说服力。2. 关键功能实现从“能跑”到“好用”2.1 数据库建模五张核心表的设计数据库设计是整个项目的地基。我刚开始写的时候图省事做了三张表用户表、课程表、预约表。结果做到预约模块时发现缺教练信息、缺会员卡有效期、缺身体记录又回头改表改了三次才稳定。后来重新梳理最终用了五张表稳住结构表名核心字段说明userid, openid, nickname, avatar, role, card_expire_daterole 区分普通会员和教练coachid, user_id, specialty, years, intro教练扩展信息和 user 表做一对一关联courseid, coach_id, name, type, start_time, end_time, max_count, booked_count, status课程排期表bookingid, user_id, course_id, status, create_time预约记录表body_recordid, user_id, height, weight, bmi, record_date会员身体指标记录表这里最大的教训是一定不要把教练当成独立用户体系来做。教练也是用户只是在 user 表里用 role 字段标识再通过一个 coach 表存扩展信息。很多项目犯的错是单独建一张 admin 表然后登录逻辑要写两套session 也要管两套纯属给自己找事。会员卡有效期我直接放在 user 表里作为 card_expire_date 字段没有单独做会员卡订单表。如果项目要求必须包含“购买会员卡”功能再外加一套 order 表也不迟。但作为最小可行性系统一个日期字段足够覆盖核心业务规则了。body_record 表是为了给系统增加一层“健身效果数据”的展示。会员在个人中心每次录入身高体重系统自动计算 BMI 并画出趋势折线图。这个功能点的开发量不大但能起到两个作用一是让论文里的“系统功能需求”多一个亮点二是演示时比反复展示增删改查有意思得多。2.2 接口协议与权限控制JWT 怎么用在微信小程序端小程序端的接口需要“认人”否则任何人都能调用预约接口。微信小程序官方登录流程是 wx.login 拿到 code后端通过 code 换 openid然后返回一个自定义的登录态标识。我选择了 JWT 作为这个标识流程如下小程序端 wx.login 获取 code调用后端/auth/login接口传入 code后端调用微信接口用 code 换取 openid查询或创建用户后端用 openid 和 userId 生成 JWT 返回给前端前端把 JWT 存到 storage后续请求放在 header 的 Authorization 字段里这样做的好处是后端接口可以写一个拦截器统一校验 Token不用在每个 Controller 里重复判断用户身份。Spring Boot 里实现也很简单写一个 HandlerInterceptor在 preHandle 方法里读取 header 中的 Token用 jjwt 解析解析成功就把 userId 放入 request context失败直接返回 401。具体拦截器核心代码大概是这样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 )) { throw new RuntimeException(未登录); } try { Claims claims Jwts.parser() .setSigningKey(SECRET_KEY) .parseClaimsJws(token.substring(7)) .getBody(); request.setAttribute(userId, claims.get(userId, Integer.class)); return true; } catch (Exception e) { throw new RuntimeException(登录已过期); } } }这里有个非常容易踩的坑微信小程序端的请求 header 必须设置正确否则后端收不到 Token。原生小程序 wx.request 的 header 默认是大写开头的 Header 名如果你的后端基于 Spring 的 CORS 配置不够宽松前端可能直接报跨域或者预检失败。我的经验是前端把所有请求统一封装到一个 request.js 里在封装函数里统一添加 header而不是每个页面单独写 wx.request。下面这段是我封装后一直很稳的写法const request (url, method, data) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method: method, data: data, header: { Content-Type: application/json, Authorization: Bearer wx.getStorageSync(token) }, success(res) { if (res.statusCode 401) { wx.removeStorageSync(token); wx.navigateTo({ url: /pages/login/login }); reject(new Error(登录过期)); } else { resolve(res.data); } }, fail(err) { reject(err); } }); }); };一开始我图省事每个页面里都直接调用 wx.request结果后来说要加 Token、要统一处理 401 时改了几十个页面改得昏天黑地。封装之后改一处就全生效这个习惯建议从一开始就养成。2.3 课程预约的逻辑时间冲突、名额限制、并发问题预约是整个系统最核心的接口也是最容易写错的接口。很多人写完预约功能就是一句 insert 进 booking 表然后 course 表的 booked_count 加一。但如果你在小程序端连续点击两次“立即预约”或者两个用户同时抢最后一节名额就会出现超卖。正确的做法是后端在事务里完成三个校验校验用户是否已约过该课程防止重复预约校验 booked_count 是否小于 max_count防止超卖校验用户当天同一时段是否已有其他预约防止时间冲突第三步是最费代码的因为需要查同一时间段是否有其他课程被该用户预约。SQL 条件大概是SELECT COUNT(*) FROM booking b INNER JOIN course c ON b.course_id c.id WHERE b.user_id #{userId} AND b.status BOOKED AND c.start_time #{endTime} AND c.end_time #{startTime}这个条件能覆盖“课程 A 8:00-9:00课程 B 8:30-9:30用户约了 A 之后不能再约 B”的场景。书写时要注意 MySQL 时间比较的边界条件我把小于和大于都取了开区间避免刚好首尾相接的课程被误判为冲突。并发问题我用 MySQL 的行级锁来处理。把更新课程人数的 SQL 写成条件更新如果影响行数为0说明已经被约满事务直接回滚int rows courseMapper.reduceOrIncreaseBookedCount(courseId, maxCount); if (rows 0) { throw new ServiceException(课程已满); }对应的 XML 是update idoccupyBookedCount UPDATE course SET booked_count booked_count 1 WHERE id #{courseId} AND booked_count max_count /update这一步非常关键。如果不加行锁两个人同时提交预约各自查到 booked_count 为 9、max_count 为 10然后都执行 insert最后就会约进 11 个人。加了条件更新以后数据库层面保证只有一个请求能把 9 变成 10另一个请求更新不到行、直接抛异常。这属于测试和答辩的高频考点务必真正理解。3. 完整实操过程与核心代码3.1 项目初始化和基础结构无论你是准备下载一套源码直接用还是准备自己写建议都先建立一个清晰的项目结构。我的项目分了两个目录miniapp放微信小程序端server放 Spring Boot 后端。小程序端目录结构如下miniapp/ ├── app.js ├── app.json ├── app.wxss ├── utils/ │ └── request.js ├── pages/ │ ├── index/ │ ├── course/ │ ├── booking/ │ ├── user/ │ └── coach/ └── components/ └── course-card/后端目录结构如下server/ ├── pom.xml ├── src/main/java/com/example/fitness/ │ ├── FitnessApplication.java │ ├── config/ │ │ └── WebConfig.java │ ├── controller/ │ │ ├── AuthController.java │ │ ├── CourseController.java │ │ └── BookingController.java │ ├── service/ │ ├── mapper/ │ ├── entity/ │ └── utils/ │ └── JwtUtils.java └── src/main/resources/ └── application.yml在 app.json 里注册页面时我把第一个页面设置成 index方便启动后直接看到首页。如果你用的是网上下载的源码第一步要检查的也是 app.json 里 pages 路径是否和 pages 目录真实文件一一对应很多下载的源码跑不起来就是因为路径写错或者缺少文件。3.2 后端接口设计与统一返回格式前后端分离的项目接口返回格式必须统一不然后端写一个样、前端解析一个样调试起来极其痛苦。我在后端定义了一个 Result 类结构固定为{ code: 200, message: success, data: {...} }所有 Controller 的方法都返回 Result异常通过全局异常处理器捕获后也包装成这个格式。小程序端在 request.js 里只判断 res.data.code 是否为 200业务错误统一通过 message 字段弹出提示。这样写的好处是前端逻辑非常简洁中断联调环节排查出错点也更容易。以课程列表接口为例Controller 的写法是RestController RequestMapping(/api/course) public class CourseController { Resource private CourseService courseService; GetMapping(/list) public Result list(RequestParam(required false) String type) { return Result.success(courseService.getCourseList(type)); } PostMapping(/create) public Result create(RequestBody Course course) { courseService.validateCoachAndTime(course); courseService.createCourse(course); return Result.success(); } }注意 create 接口里先调了一个 validateCoachAndTime 方法它负责检查教练身份和排课时间冲突。这个检查被我单独抽了出来而不是写在 createCourse 里。原因很简单接口职责单一Controller 只负责参数接收Service 里先校验后处理后续如果增加“批量导入课程”功能这层校验也能直接复用。3.3 教练端排课接口与时间冲突校验教练端最核心的接口是排课。排课时要传课程名称、课程类型、开始时间、结束时间和最大人数。后端拿到数据后需要校验两件事这个用户是不是教练以及这段时间教练有没有已经存在的课。校验时间的 SQL 语句可以复用预约冲突查询的思路但是把 user_id 换成 coach_id 即可select idcountConflictByCoach resultTypeint SELECT COUNT(*) FROM course WHERE coach_id #{coachId} AND status ! CANCELLED AND start_time #{endTime} AND end_time #{startTime} /select如果返回数量大于0直接抛业务异常提示“该时间段已有课程安排”。这个校验能保证教练的一天不会出现重叠的课程防止会员约了两门其实同一教练上的课。我在这个模块里额外加了 status 字段做课程状态管理。排课创建后默认是 PUBLISHED如果教练临时有事可以把课程设为 CANCELLED。取消的同时需要把所有已预约这条课程的会员预约记录也改为 CANCELLED并且回退 booked_count。这是一个非常容易被漏掉的地方如果你只改了课程状态会员端还在排着队上课就尴尬了。具体的取消逻辑写在 Service 里用Transactional注解保证要么全部成功、要么全部失败Transactional(rollbackFor Exception.class) public void cancelCourse(Integer courseId) { Course course courseMapper.selectById(courseId); if (course null) { throw new ServiceException(课程不存在); } // 更新课程状态为已取消 course.setStatus(CANCELLED); courseMapper.updateById(course); // 将已预约记录状态置为已取消 bookingMapper.cancelByCourseId(courseId); }这里事务非常关键。如果取消课程之后、更新预约记录之前程序崩了就会出现课程没了但预约记录还挂着的脏数据。加了事务后任一步失败都会完全回滚数据库始终处于一致状态。3.4 会员端预约与签到流程会员端预约流程我分了四步进入课程详情页 - 展示课程剩余名额和开课时间 - 点击预约按钮 - 后端校验并写入预约记录。预约成功后前端把按钮文案改为“已预约”并置灰防止重复操作。预约接口的完整校验顺序是根据 courseId 查询课程课程不存在或已取消直接抛异常比较当前时间和课程开始时间开课前30分钟内或已经开始就不允许预约校验会员卡有效期card_expire_date 小于当前日期则提示先续费校验同一时段冲突尝试执行 update course set booked_count booked_count 1 where booked_count max_count受影响行数为0则提示课程已满插入预约记录这六步的操作顺序一定要固定先更新课表名额再插入预约记录可以避免脏数据插入后还要回滚的麻烦。我在实际调试中发现如果把第5步和第6步对调极端情况下可能出现预约记录插入成功但名额扣减失败的问题导致会员显示已约但课程名单里没这个人。签到功能我实现得比较轻量会员课程开始时到达健身房扫描前台展示的课程二维码上传课程 ID后端把 booking 的状态从 BOOKED 改为 CHECKED。这个功能如果一开始觉得复杂用“点击签到按钮 定位校验”也可以管理员在管理端按下发课程验证码会员输入后签到同样是一条完整的功能链路。3.5 数据统计会员端身体指标图表数据统计我选择了最务实的两块课程预约情况的统计以及会员身体指标的记录。课程预约统计通过后端接口返回近7天每日预约人数前端使用小程序原生的 slider 视图或者简单的 canvas 图表绘制柱状图。为了减少开发量我直接用了 echarts-for-weixin 这个开源适配组件。使用方式很简单在 package.json 引入 ec-canvas 组件然后在页面 json 文件里注册在 wxml 放置 canvas再在 js 里配置 option 即可。身体指标记录的接口更简单本质上是 body_record 表的增查。会员每次录入身高体重后后端自动计算 BMI 并存入表里查询时按时间倒序返回最近30条数据前端渲染成趋势线。计算 BMI 的代码就一行double bmi weight / Math.pow(height / 100.0, 2);但要注意单位。我最初写的时候直接用了体重公斤除以身高米结果前端显示出来全是 0.002 这种值排查半天才发现身高没有从厘米换算成米。这种小问题在项目联调时最容易耗时间如果你也做类似功能第一件事就是约好前端字段单位。3.6 论文说明的结构与代码怎么对应论文是这套项目的重要组成部分但很多人的论文和代码是“两张皮”代码里没有的东西论文里写了一大堆答辩时一问就穿帮。我的论文结构是按经典毕设的八章走的绪论、相关技术、需求分析、系统设计、系统实现、系统测试、总结与展望、参考文献。写论文时必须做到“一个功能点对应一个实现小节”不要泛泛而谈。比如写“课程预约模块”正文大概率是先描述需求再贴数据库表结构再贴核心接口代码然后放两张运行截图最后给一段测试说明。这样整篇论文谈的都是这一个功能逻辑紧凑随便问哪一章你都能答上。有一段回答是很多评委必问的“你这个系统最多能撑多少人同时使用”这问题看着像压力测试实际是考你对并发控制理解的程度。我准备了两个层面的回答数据库层面预约时使用的行级更新保证不会超卖应用层面当前系统受限于小程序端性能和单机部署适合中小型健身房使用。这就够了。4. 常见问题与排查技巧实录4.1 顶部导航栏高度与 iPhone 适配问题微信小程序的顶部导航栏在不同机型上高度不一致尤其是现在 iPhone 带灵动岛的机型。很多页面写死了一个导航栏高度结果在 iPhone 14 Pro 上被挖孔遮挡在安卓上又留了过多空白。正确做法是用微信提供的胶囊按钮位置信息动态计算。我在 app.js 的 onLaunch 里做了这样一段计算const getNavBarInfo () { const systemInfo wx.getWindowInfo(); const menuButton wx.getMenuButtonBoundingClientRect(); const navBarHeight (menuButton.top - systemInfo.statusBarHeight) * 2 menuButton.height; const statusBarHeight systemInfo.statusBarHeight; this.globalData.navBarHeight navBarHeight; this.globalData.statusBarHeight statusBarHeight; };计算出高度后页面在使用自定义导航栏时直接读取 globalData 里的值来设置站位 view 的高度。这样无论什么机型导航栏都不会被遮挡。我在开发中曾经用固定 44px 的导航栏高度测试用的安卓机没问题一到 iPhone 12 上就顶到状态栏里去改成动态计算一劳永逸。4.2 请求失败的排查顺序先分前端还是后端小程序请求接口失败很多同学第一反应就是“后端报错了”结果后端日志啥也没有其实是前端域名没配好。我整理了一个排查顺序按顺序走一般十分钟内能定位优先级检查项现象1开发者工具里是否勾选“不校验合法域名”报 url not in domain list2真实手机调试时是否已在小程序后台配置 request 合法域名手机上请求直接 fail3后端接口是否允许跨域浏览器调试报 CORS 错4请求 header 是否包含完整的内容类型和 Token后端收不到参数或报 4015后端服务是否真的启动、端口是否被占用连接被拒绝这里最容易忽略的是第2条。开发者工具里关掉合法域名校验后接口正常换到手机预览所有请求全部失败。原因就是工具和真机的校验策略不同真机必须在小程序管理后台把 HTTPS 请求域名加进白名单。如果你在本地用 http:// 开发可以临时开启“调试模式”但如果要提交体验版或者审核必须配置正式域名。4.3 登录态失效Token 过期和用户信息获取Token 过期是小程序项目里非常容易出现的体验问题。JWT 一般来说是无状态的服务端设置了两小时过期时间前端在拦截器里判断 401 后跳回登录页。但这样有个尴尬的场景用户正在填写身体记录突然跳回登录页填的一大堆数据全丢了。我的处理方式是在 request.js 的 401 分支里显示一个 toast 提示“登录已过期请重新登录”然后跳转到登录页而不是静默跳转。同时把所有表单类页面的输入状态保存在页面的 data 里重新登录后返回原页面时数据依然还在。这个细节看着小实际上是真实用户和使用者能感知到的关键体验。获取用户头像昵称也是变过规则的。从微信基础库 2.21.2 开始wx.getUserProfile 和 wx.getUserInfo 都无法直接返回真实的头像和昵称官方推荐使用“头像昵称填写能力”——用户在小程序里自行选择头像、输入昵称存到你的后端。我建议登录页直接做成用户点击登录 - wx.login 获取 code 并调用后端登录接口登录成功后进入“完善资料”页面展示昵称输入框和头像选择器用户保存后将 headImageUrl 和 nickname 提交到后端更新用户资料这样彻底绕开了官方信息获取接口的限制也符合微信最新的用户隐私政策要求。另一个常见问题是隐私协议设置如果小程序调用了用户相册、位置等接口必须在后台配置用户隐私保护指引否则调用对应 API 会直接报权限错误这是很多同学用别人的源码后遇到的第一个拦路虎。4.4 支付模块能做但要想清楚边界健身管理系统经常被要求加上支付模块用于线上购买会员卡。这个功能能做但有两个坑必须提前想清楚。第一个坑是资质。微信支付需要商户号个人主体的开发者无法开通。如果你只是做毕设没有企业资质可以用模拟支付的方式前端调用后端生成订单后端模拟支付成功直接改变会员状态。在论文里写清楚“支付模块采用模拟支付方式完成业务验证”即可答辩老师基本都能理解。第二个坑是苹果虚拟支付。如果这套小程序要过审而你在 iOS 端售卖会员卡这类虚拟服务必须接入苹果的 IAP 支付不能用微信支付否则有被拒风险。个人开发者的普通毕设项目很难处理这层兼容所以我的建议是用免费试用、后台手动开通会员卡的方式替代线上购买核心业务流程仍然完整但规避了支付资质和审核风险。4.5 答辩高频问题清单最后整理一份答辩现场比较容易出现的问题建议在提交之前把每一个都能顺畅回答为什么选择微信小程序而不是原生 App——开发成本、用户免安装、微信生态内传播、适合轻量级业务场景预约接口如何防止超卖——条件更新 SQL 数据库行锁事务内完成课表名额扣减和预约记录写入你如何理解 MVC后端代码哪里体现 MVC——Controller 接收参数、Service 写业务逻辑、Mapper 操作数据库系统性能瓶颈在哪里——小程序端渲染性能和单机数据库连接数是当前的上限必要时可加缓存密码安全怎么做的——小程序场景主要依赖微信 openid 体系服务端不存密码管理员密码使用 BCrypt 加密存储如果用户量从100增长到10万哪里会先崩溃——数据库连接池需要引入 Redis 缓存以及把服务水平扩展这些问题没有标准答案但你必须能说出你自己系统的真实情况哪怕你的回答不完美也比背网上的套话管用。最后说点实在的这套系统的完整做法写到这儿核心的点基本都覆盖了。我始终觉得能不能做出来不重要重要的是你在做的过程中有没有真正踩过坑、然后填上坑。我的第一个预约接口就没有加并发控制第一次自测时用两个账号同时抢最后一节课还真出现了一方预约成功、另一方也提示成功的问题。后来才补了条件更新 SQL也因为这个过程我对事务、行锁的理解比任何教科书都深刻。最后分享一个小技巧整个项目完成后把所有接口的请求和响应截几张完整的图放到论文的“系统测试”章节里。截图最好包含 URL、请求头、返回体三个部分这样评审老师能直接看到前后端联调的真实结果比我在这篇文章里写一千个理论都有效。如果你也在做类似的健身管理系统按这个思路去实现项目源码的质量不会差的。
