先给结论微信小程序健身房管理系统不是把健身房的业务流程搬到手机上就行而是要把“会员办卡、课程预约、私教约课、到场核销、余额消费、通知触达”这一整条交易链条在小程序端、后端接口、管理后台和数据库之间跑通。这篇文章适合准备做毕设、想接健身房管理系统需求、或者正在从零搭建小程序的开发者。最值得先想清楚的不是页面多好看而是业务上有哪些角色、哪些状态、哪些流程会互相影响。我按实际落地顺序拆一遍先做业务梳理再做技术选型然后设计数据库和接口再把小程序端关键页面跑通最后处理微信支付、预约并发和部署上线。整个过程按能复现的标准来写参数、表结构、接口路径、排查顺序都会给到。1. 先确认健身管理系统要管的“状态”有哪些很多新手拿到“健身房管理系统”这个题目第一反应是先写页面。首页放轮播图下面放课程列表看起来像个 App 就开始了。这样做后面一定会返工因为管理系统的核心不是页面是“状态”。1.1 健身房业务里有哪些核心角色一套微信小程序健身管理系统通常要服务三类角色普通会员通过小程序注册登录、浏览课程、预约团课、约私教、购买会员卡、查看课时和消费记录。前台/教练处理会员到店核销、课程签到、私教课扣课时、学员信息查看。超级管理员维护门店信息、教练资料、课程排期、会员卡类型、订单退款查看经营数据。这三类角色如果放在一个表里用 level 字段区分前期开发方便但后期权限判断会越堆越乱。我的习惯是用户表只放 openid、手机号、昵称、头像、状态把角色关系单独拆出来。小程序端通过登录接口拿到用户 ID 后后端根据角色返回不同的菜单和接口权限。1.2 核心业务状态怎么设计健身房管理不是一个静态信息展示它每个环节都有状态流转。先把状态清单列出来后面做表和接口时就不会乱会员卡状态未激活、有效、已过期、已退款。会员卡次数总次数、已用次数、剩余次数私教课和团课要分开算。课程状态待开始、进行中、已结束、已取消。预约状态已预约、已取消、已核销、已爽约。订单状态待支付、已支付、已退款、已关闭。退款状态无、申请中、已退款、退款失败。注意会员卡剩余次数不要只存一个数字。更稳妥的做法是存一张“课时流水表”每次核销、取消、退款都写一条带类型的时间记录。这样就算会员投诉说“我明明还有 3 节课”你也能拿出流水来核对。只改剩余次数字段的方案一旦并发请求覆盖次数会出错且查不到原因。1.3 把业务流程画成闭环小程序端最常见的流程是会员选择团课 → 查看课程详情和剩余名额 → 提交预约 → 微信支付或消耗已购卡次数 → 后台生成预约记录 → 用户到店后出示核销码 → 前台扫码核销 → 状态变为已核销。私教课的区别在于用户先选择教练再选择教练的可约时间段支付或扣除课时后锁定该时间段。这里比团课多一个“教练排期表”需要防止两个会员约到同一个教练的同一时段。如果涉及会员卡购买还需要额外处理用户购买后是否立即生效、是否支持多张卡叠加、退款时是否返还已核销课时。这些业务规则必须在后端接口层做校验不能依赖小程序端的按钮状态。注意不要在小程序端判断“用户有没有权限”小程序端可以被构造请求。所有金额计算、库存扣减、次数扣减都要在后端做。2. 技术选型小程序端、后端、数据库、部署环境这套系统我建议用“原生微信小程序 Spring Boot MySQL Redis”的组合。这个组合不算最新潮但资料多、排错容易、适合毕设和中小型健身房落地。如果你更熟悉 Node.js也可以用 Express/NestJS 替换 Spring Boot核心设计不变。2.1 前端用原生还是 uni-app原生微信小程序适合你只需要发布到微信平台、不想引入额外框架的情况。开发时用微信开发者工具打开组件和 API 最直接。uni-app 的优势是一套代码可以编译到多端比如 H5、支付宝小程序。如果你的项目以后可能要出 App 或网页端选 uni-app 更省事。缺点是遇到平台差异时还得单独写条件编译调试链路比原生长一点。我个人的建议是毕设或者单点功能项目直接用原生要商业交付且客户强调后续多端再选 uni-app。不要为了“技术栈好看”而选重框架项目能按时交付、能稳定运行比什么都重要。2.2 后端按模块拆分后端建议按业务模块分包不是按技术类型分包。也就是说不要建一堆 controller、service、mapper 文件夹把所有类堆在一起而是按 member、course、appointment、order、payment、admin 模块来分。每个模块里包含 Controller、Service、Mapper、Entity、DTO。这样别人看代码时从一个模块进去就知道这个功能涉及哪些文件。比如处理预约退款直接进 appointment 模块找对应 Service而不是先找 controller 再猜 service。Spring Boot 版本建议选 2.7.x 或 3.x 中你已经熟悉的稳定版。如果学校课程教的是 2.x就不要强行上 3.x避免 Jakarta 命名空间和配置差异影响进度。2.3 数据库和缓存MySQL 负责核心数据存储。表结构使用 utf8mb4 字符集因为小程序用户昵称里经常有特殊字符和 emojiutf8mb4 才能正常保存。Redis 在初期可以不用但当预约、下单人数上来后推荐用它做两件事课程剩余名额的预扣减以及微信 access_token 的缓存。access_token 每天有调用次数限制不能每次都向微信服务器请求。文件存储方面小程序端上传图片可以用微信云开发的云存储也可以用后端接阿里云 OSS 或腾讯云 COS。如果只是本地开发先存服务器本地目录就够了部署时再换对象存储。2.4 环境准备清单开发这套系统至少需要准备以下环境环境项建议配置说明微信开发者工具最新稳定版用于小程序端开发调试JDK1.8 或 17与 Spring Boot 版本匹配Maven3.8管理后端依赖MySQL5.7 或 8.0业务数据库Redis5.x 以上缓存和库存预扣减微信小程序 AppID已注册的小程序测试号和正式号分开内网穿透工具可选本地开发时给微信服务器回调用如果你没有注册小程序可以去微信公众平台申请一个个人主体的小程序。个人主体能使用大部分基础能力但微信支付需要企业主体。纯学习阶段可以先模拟支付上线前再申请商户号。3. 数据库表结构先有表再写接口数据库是整个管理系统的地基。表设计不合理后面写接口时经常要改表结构改表结构又会影响已经写好的代码。我建议先设计好核心表再动手写接口。3.1 用户与会员表用户表主要存微信身份和基本信息CREATE TABLE user ( id bigint NOT NULL AUTO_INCREMENT, openid varchar(64) NOT NULL COMMENT 微信openid, unionid varchar(64) DEFAULT NULL COMMENT 微信unionid, nickname varchar(64) DEFAULT NULL COMMENT 昵称, avatar varchar(255) DEFAULT NULL COMMENT 头像URL, phone varchar(20) DEFAULT NULL COMMENT 手机号, role tinyint NOT NULL DEFAULT 1 COMMENT 角色 1会员 2教练 3管理员, status tinyint NOT NULL DEFAULT 1 COMMENT 状态 1正常 0禁用, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;会员卡表单独设计因为一个用户可能有多张卡不同卡的规则不一样CREATE TABLE member_card ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL COMMENT 用户ID, card_type_id bigint NOT NULL COMMENT 卡类型ID, total_count int DEFAULT 0 COMMENT 总次数0表示不限次, used_count int DEFAULT 0 COMMENT 已用次数, start_time datetime DEFAULT NULL COMMENT 生效时间, end_time datetime DEFAULT NULL COMMENT 失效时间, status tinyint NOT NULL DEFAULT 0 COMMENT 状态 0未激活 1有效 2过期 3退款, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT会员卡表;3.2 教练、课程与排期教练表不要写死字段性别、教龄、擅长领域、头像都是基本信息。预约相关的是教练的服务时间配置CREATE TABLE coach ( id bigint NOT NULL AUTO_INCREMENT, name varchar(32) NOT NULL, avatar varchar(255) DEFAULT NULL, title varchar(64) DEFAULT NULL COMMENT 职称如高级私教, years int DEFAULT NULL COMMENT 教龄, intro text COMMENT 简介, status tinyint NOT NULL DEFAULT 1, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT教练表;课程表分为“课程模板”和“课程排期”两段。课程模板描述课程是什么比如“动感单车”“瑜伽入门”。课程排期描述具体某一天的 19:00 在哪间教室上课由哪个教练带课CREATE TABLE course_schedule ( id bigint NOT NULL AUTO_INCREMENT, course_id bigint NOT NULL COMMENT 课程模板ID, coach_id bigint NOT NULL COMMENT 教练ID, start_time datetime NOT NULL, end_time datetime NOT NULL, total_slots int NOT NULL DEFAULT 0 COMMENT 总名额, booked_slots int NOT NULL DEFAULT 0 COMMENT 已预约名额, status tinyint NOT NULL DEFAULT 0 COMMENT 状态 0未开始 1进行中 2已结束 3取消, create_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_start_time (start_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT课程排期表;预约记录表需要同时支持团课和私教课用预约类型区分CREATE TABLE appointment ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL, appointment_type tinyint NOT NULL COMMENT 1团课 2私教, schedule_id bigint DEFAULT NULL COMMENT 团课排期ID, coach_time_id bigint DEFAULT NULL COMMENT 私教时间段ID, status tinyint NOT NULL DEFAULT 0 COMMENT 0已预约 1已取消 2已核销 3已爽约, source tinyint NOT NULL DEFAULT 1 COMMENT 来源 1次卡 2储值 3微信支付, order_id bigint DEFAULT NULL COMMENT 关联订单ID, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_schedule_id (schedule_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT预约记录表;3.3 订单与支付流水订单表记录所有交易支付流水表记录微信支付回调后的详细信息。注意区分这两个概念订单是业务数据支付流水是支付结果数据。一个订单可以对应多条流水比如一次支付成功、一次退款成功。CREATE TABLE orders ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 业务订单号, user_id bigint NOT NULL, total_fee int NOT NULL COMMENT 金额单位分, pay_type tinyint NOT NULL COMMENT 支付方式 1微信支付, status tinyint NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已退款 3已关闭, out_trade_no varchar(64) DEFAULT NULL COMMENT 微信支付商户订单号, transaction_id varchar(64) DEFAULT NULL COMMENT 微信支付交易号, create_time datetime NOT NULL, pay_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;金额统一用 int 存“分”不要用 double 或 float。存小数会导致金额计算出现精度问题比如 0.1 加 0.2 得到 0.30000000000000004。接口返回给前端时再转成元。4. 小程序端核心页面与接口设计数据库设计好后建议按“登录 → 首页课程列表 → 课程详情 → 提交预约 → 支付/扣次数 → 用户中心核销记录”这条主线先跑通。不要一开始就做后台管理端那会分散精力。4.1 小程序登录流程微信小程序的登录流程是小程序端调用 wx.login 获取 code把 code 发给后端后端用 code 调用微信的 code2Session 接口换取 openid然后后端根据 openid 查找或创建用户返回自定义登录态 token。token 建议使用 JWT 或随机字符串存在 Redis 里。每次小程序端请求接口时在 header 中携带 token后端通过拦截器解析用户信息。不建议把 openid 直接放在前端请求参数里容易被拿到后越权访问他人数据。这里要特别注意以前很多教程让用户点按钮触发 wx.getUserProfile 获取头像昵称但微信官方后来调整了规则 getUserProfile 返回的头像昵称变成了默认灰色头像和“微信用户”。 现在的做法是引导用户在小程序内自行填写昵称、上传头像或者使用头像昵称填写能力。// 小程序端登录示例 wx.login({ success: async (res) { const code res.code const loginRes await request.post(/auth/login, { code }) wx.setStorageSync(token, loginRes.data.token) } })后端登录接口的大致逻辑PostMapping(/auth/login) public Result login(RequestBody LoginRequest req) { String openid wxService.code2Session(req.getCode()); User user userMapper.selectByOpenid(openid); if (user null) { user userMapper.insert(openid); } String token redisService.createToken(user.getId()); return Result.success(token); }4.2 首页课程列表与详情首页展示的核心数据就是课程排期列表。按开始时间倒序或正序筛选状态为“未开始”的课程。小程序端用 scroll-view 做下拉刷新或者直接用页面自带的 onPullDownRefresh。课程列表接口建议一次不要返回全部字段否则列表接口会越来越重。首页列表只需要 id、课程名、教练名、开始时间、剩余名额。课程介绍、教练详情、注意事项放到详情接口里用户点击进入后再请求。GetMapping(/course/list) public Result list(RequestParam Integer page, RequestParam Integer size, RequestParam(required false) LocalDate date) { PageHelper.startPage(page, size); ListCourseVO list courseService.listAvailable(date); return Result.success(list); }4.3 预约时最重要的是“名额判断”用户提交预约时很多人只在前端判断剩余名额是否大于 0这是不安全的。正确做法是后端在事务里先查 schedule 的 booked_slots再和 total_slots 比较然后 update 增加 booked_slots。这个操作在并发情况下会存在超卖风险。最简单的处理方式是利用 SQL 条件更新UPDATE course_schedule SET booked_slots booked_slots 1 WHERE id #{scheduleId} AND booked_slots total_slots AND status 0如果 update 影响行数为 1说明名额扣减成功继续插入预约记录如果影响行数为 0说明名额已满或课程状态不对直接返回“名额不足”。这种方案适合预约量不大、单机部署的健身房系统。如果以后访问量上来了可以再用 Redis 的 Lua 脚本做更严格的库存扣减。4.4 核销码和到店核销预约成功后小程序端用户中心展示预约记录和核销二维码。这个二维码内容通常是一串带签名参数的预约编号比如预约 ID 加一个只有后端知道的签名串。前台核销时打开管理端小程序或后台页面扫描二维码后后端解析预约编号校验签名、预约状态和当前时间把预约状态改为已核销。如果会员是次卡支付还要同步扣减 member_card 的 used_count并写入课时流水表。核销这个环节是很多初版系统容易漏掉的只做了预约没有核销导致教练和前台只能靠口头确认人数。管理系统的闭环一定要包含核销。5. 微信支付 V3 对接从小程序下单到回调处理微信支付是这套系统里最容易出问题的环节。常见的问题包括支付后没有回调、回调验签失败、平台证书找不到、订单金额不对。原因大多不是微信支付本身难而是配置和签名环节没理解清楚。5.1 接入前的配置清单小程序支付需要三个关键配置AppID、商户号、APIv3 密钥。此外还需要证书包括商户 API 证书和证书序列号用于请求签名以及微信支付平台证书用于验证微信回调的签名。在微信支付商户平台里需要配置 APIv3 密钥并且下载商户 API 证书。证书文件一般包括 apiclient_cert.pem 和 apiclient_key.pem。开发者要妥善保存不要把私钥上传到公开代码仓库。支付回调地址也需要在商户平台配置而且回调地址必须是可以被微信服务器访问的公网地址。本地开发时可以用内网穿透工具把本机接口暴露到公网但要注意只用于开发和测试。5.2 小程序端发起支付小程序端拿到后端生成的支付参数后调用 wx.requestPaymentconst payRes await request.post(/payment/create, { orderNo: orderNo }) wx.requestPayment({ timeStamp: payRes.data.timeStamp, nonceStr: payRes.data.nonceStr, package: payRes.data.package, signType: RSA, paySign: payRes.data.paySign, success: () { // 支付成功以后端回调为准 }, fail: (err) { // 用户取消或支付失败 } })支付成功的前端提示只能作为参考真正确定订单是否支付成功必须以微信服务器回调后端接口的结果为准。后端生成支付参数的逻辑是创建商户订单号调用微信支付 V3 的 JSAPI 下单接口传入 appid、mchid、description、out_trade_no、notify_url、amount 等参数。请求签名使用商户私钥使用 RSA-SHA256 算法。5.3 回调处理验签、解密、更新订单微信支付回调的逻辑必须要稳。回调可能会重复发送而且发送顺序不保证。处理回调时要注意幂等性同一个订单被回调多次不能重复更新业务数据。回调处理步骤接收微信服务器的 POST 请求。从 headers 中获取 Wechatpay-Signature、Wechatpay-Timestamp、Wechatpay-Nonce、Wechatpay-Serial。使用微信支付平台证书验签。验签通过后解密 resource 中的 ciphertext。解析出 out_trade_no 和 transaction_id。根据 out_trade_no 查询订单。如果订单状态已经是“已支付”直接返回成功不重复处理。更新订单状态、支付时间、微信交易号。给用户开通会员卡或增加课时。返回{code: SUCCESS, message: 成功}。实际开发中我见过很多人在回调里直接解析 JSON忘记了验签。这样一旦周围有人拿到你的回调地址就可以伪造支付成功通知。验签和幂等处理是必须的不是可选项。5.4 平台证书问题的处理思路很多开发者做微信支付 V3 对接时报“无可用的平台证书”然后去商户平台申请证书。实际上微信支付 V3 的官方 Java SDK 支持自动下载和更新微信支付平台证书。只需要配置商户号、商户私钥、商户证书序列号、APIv3 密钥SDK 会在初始化时自动获取平台证书。如果你用官方 SDK 仍然报证书问题按以下顺序排查排查点判断标准商户私钥文件路径是否正确是否包含完整私钥内容商户证书序列号是否和商户平台显示的序列号完全一致APIv3 密钥是否 32 字节创建后不能修改网络访问服务器能否正常访问微信支付接口域名SDK 版本是否使用较新的 V3 SDK关于支付公钥和平台证书的区别不必过度纠结。V3 推荐使用“微信支付平台证书”用于验签。如果你的业务系统依赖回调确认订单必须把验签流程打通。6. 后台管理端排课、核销、数据统计后台管理端可以做成另一个小程序页面组也可以做成 Web 管理系统。如果时间有限我建议先做一个小程序管理端不需要额外搭前端框架直接复用微信开发者工具的组件体系。6.1 管理端最少要包含哪些功能排序重要度会员列表查看会员、禁用账号、重置密码。课程排期管理创建课程排期、取消课程、查看预约名单。核销入口扫码核销、手动输入预约编号核销。教练管理维护教练资料和可预约时间。会员卡管理创建卡类型、查看售卡记录。订单列表查看订单、处理退款。数据看板今日预约数、今日营收、会员增长数。前三个功能没有系统没法真正运营后面几个可以根据需求分阶段补。6.2 排课时的规则校验排课接口有一个核心校验同一个教练在同一时间段不能重复排课。这个校验不能只靠人工看后端要做查询判断。同时一个团课教室的同一时间也不能重复排课。实现时先查询冲突记录SELECT COUNT(*) FROM course_schedule WHERE coach_id #{coachId} AND start_time #{endTime} AND end_time #{startTime} AND status IN (0, 1)查询结果大于 0说明时间段冲突直接返回错误。私教课的教练时间配置类似但粒度更细。建议单独建一张 coach_time_slot 表记录教练可约的每个时间段会员预约私教时锁定时间段这样可以避免手工判断时间字符串。6.3 数据统计怎么设计统计报表不要在查询时做复杂的多表 join 和全表扫描。更常用的做法是每天凌晨用定时任务统计前一天的数据写入一张 dashboard_daily 表。后台首页查报表时直接查这张汇总表速度快也不会影响业务库。统计指标至少要包含新增会员数活跃会员数当日有预约或消费预约总量和核销率课程取消率会员卡销量和销售额课程热度排行核销率是健身房运营的重要指标。核销率低说明预约后很多人不来要么是爽约成本太低要么是课程排期不合理。系统里把这个指标做出来比单纯做一个花哨的图表更有价值。7. 常见问题排查顺序微信小程序健身管理系统开发过程中很多问题不是单点原因而是一连串前置条件没满足。我按实际频率整理一份排查顺序遇到问题时按这个链路走能省不少时间。7.1 登录失败先确认 wx.login 拿到的 code 是否有效。code 只能使用一次有效期为五分钟。如果频繁测试同一个 code 不能重复提交。再确认后端调用 code2Session 时 appid 和 secret 是否配置正确。这里特别容易踩坑用了测试号 AppID后端配置却是正式号或者反过来。小程序端和后端的 appid 不一致openid 就匹配不上。最后检查后端日志看微信接口返回的 errcode。如果是 40029说明 code 无效如果是 40163说明 code 被重复使用。不要只看前端报错后端日志才是定位关键。7.2 支付支付后订单状态没变如果用户微信支付弹窗显示成功但订单还是待支付基本是两种情况第一种是没配回调地址或回调地址不可访问。微信服务器请求不到你的接口自然没法通知后端更新订单。第二种是回调验签失败或者接口内部报错。去后端日志里搜 notify 关键词看请求有没有进来处理过程中哪一步抛了异常。常见原因包括平台证书配置不对、AES 解密失败、订单号为空、修改订单时 SQL 出错。不要在前端用 setTimeout 去轮询订单状态来“假装”支付成功。支付确认必须以后端回调为准。7.3 课程名额超卖或预约后无法核销名额超卖如果已经发生先查预约记录的数量是否大于课程总名额。如果是说明并发场景下 update 条件没有生效可能原本就用了普通的 select 再 update。核销失败则按下述顺序查核销码是否过期或签名错误。预约状态是否已经是已核销。当前时间是否在课程开始前后允许核销的时间窗口内。用户显示的是课程预约码还是会员二维码很多人把这两个码搞混。核销逻辑里建议加上“允许核销时间段”参数比如课程开始前 30 分钟到课程结束后 30 分钟。不在时间窗口内就提示无法核销避免太早核销导致会员实际没到场也避免结束后很久还能核销。7.4 头像昵称获取不到现在不要再写wx.getUserProfile获取真实头像昵称的逻辑了。微信调整策略后该接口返回的是默认头像和“微信用户”。正确的做法是提供头像上传和昵称输入组件让用户在小程序内维护自己的资料。或者使用微信官方推荐的“头像昵称填写能力”在 form 表单里放 button open-typechooseAvatar 和 input typenickname。这个改动不复杂但很多老教程没更新照着抄就会踩坑。7.5 数据库连接不稳定如果数据库在本地小程序通过后端访问要注意后端服务器是否能访问到数据库地址。地址不要用 localhost要确认后端进程所在的机器和 MySQL 在同一网络内。另外连接池参数要设置合理。初始连接数可以小一点最大连接数根据业务量调整。连接超时时间不要太短尤其是微信支付后回调接口要查询和更新数据库如果连接超时配置过短回调处理容易失败。8. 从本地开发到上线部署的完整路径本地跑通只是第一步。真正上线部署时还有一批问题和本地环境完全不同域名、HTTPS、服务器资源、日志、备份。8.1 上线前必须准备的账号和环境微信小程序正式发布需要已认证的小程序账号。支付需要企业主体个人主体无法开通微信支付。如果客户是健身房一般以健身房营业执照申请商户号。小程序后台需要配置服务器域名。request 合法域名必须是 HTTPS且不能带端口。开发时可以在开发者工具里勾选“不校验合法域名”来临时绕过但上线前一定要把域名配置好。建议域名结构这样设计api.yourdomain.com小程序后端接口admin.yourdomain.comWeb 管理后台如果有static.yourdomain.com静态资源或上传图片8.2 部署步骤后端部署我建议用 Docker Compose 一键启动这样 MySQL、Redis、后端服务可以统一管理。如果服务器配置紧张也可以直接通过 Maven 打包成 jar用 nohup 启动。部署顺序安装 Docker 和 Docker Compose。创建 docker-compose.yml定义 mysql、redis、app 三个服务。准备 MySQL 初始化脚本创建数据库和表。配置后端 application-prod.yml把数据库地址、Redis 地址、微信支付参数换成生产配置。构建后端镜像并启动。配置 Nginx 反向代理把 HTTPS 请求转发到后端端口。在小程序后台配置 request 合法域名和业务域名。用微信开发者工具上传代码提交审核。version: 3 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: yourpassword MYSQL_DATABASE: gym ports: - 3306:3306 volumes: - ./mysql-data:/var/lib/mysql - ./init.sql:/docker-entrypoint-initdb.d/init.sql redis: image: redis:7 ports: - 6379:6379 app: build: . ports: - 8080:8080 depends_on: - mysql - redis environment: SPRING_PROFILES_ACTIVE: prod8.3 上线后要盯哪些数据上线不是终点。系统落地后至少观察以下数据支付回调成功率看日志里是否有回调失败或超时。预约接口响应时间如果超过 2 秒就要检查数据库索引和慢查询。数据库增长量预约记录和课时流水表增长很快要提前规划备份策略。服务异常告警建议接入简单的日志监控或者至少定时检查进程是否存在。我做过太多项目很多在开发阶段一切正常上线后第一天就遇到支付回调失败、课程预约并发导致名额错乱、服务器磁盘被日志撑满。所以上线第一周每天抽十分钟看一次日志很有必要。8.4 如果只是毕设可以简化到什么程度如果这是毕设项目不涉及真实商业运营可以适当简化支付流程可以用一个模拟支付按钮替代后端直接生成已支付订单。核销可以不做扫码手动输入预约编号核销。服务器部署可以用本地局域网演示不强制上云。数据统计做一个基础版今日预约数、会员数、营收三个指标就够。但核心的表结构、预约状态流转、后端权限校验、排序和分页这些能力不能省。因为答辩老师主要看的不是支付是否真实而是你是否理解业务流程、代码结构是否清晰、遇到异常情况是否有处理方案。9. 最后留几个我会优先检查的点如果你打算自己复现这个项目我建议按下面的顺序验收系统同一用户能否重复预约同一节团课后端是否有拦截。课程满员后继续提交预约返回是否友好。预约成功后取消名额是否恢复。用户支付后没有回调运营人员能否手动补单。会员卡过期后继续预约后端是否拒绝。管理员能否查看每个预约的操作日志或时间线。这些问题看起来小但都是健身房运营中真正会遇到的场景。把这些边界处理到位系统才算真的可用。不要只满足于“页面能打开、数据能插入”那和真实管理系统还有很大距离。整套系统做完你的收获不只是“会写一个微信小程序”而是理解了一条完整业务链从用户身份识别、业务状态流转、支付回调、并发控制到最后部署上线。这套思路以后换任何行业系统都可以复用。