微信小程序健身房管理系统：从预约并发到会员卡设计全解析-平芜编程栈

1. 这篇文章真正要解决的问题

很多同学做微信小程序相关的课程设计或毕业设计时，最容易遇到的情况是：需求文档只有一句话——“做一个健身房管理系统”，剩下的全靠自己猜。课程表怎么排？会员怎么管理？私教课怎么约？教练排班怎么处理？如果一开始没有想清楚系统边界，很容易把项目做成一个“看起来功能很多、实际逻辑混乱”的演示 Demo。

我们需要明确判断：健身房管理系统这类小程序，真正的难点并不在小程序界面好不好看，而在于预约类业务的状态管理。你可以在前端写出漂亮的课程卡片，但如果后端没有处理好“同一时间段只能约一个教练”“会员卡到期不能预约”“课程满员后自动关闭预约”这一系列逻辑，那项目就只是花架子。

这篇文章会从实际开发角度，完整拆解一个基于微信小程序的健身房管理系统的设计与实现过程。你不仅能看懂页面结构，还能拿到可以直接跑通的后端接口设计、数据库表结构、小程序端请求代码，以及对预约冲突、支付接入、订阅消息、真机调试等常见问题的排查思路。

阅读本文前，你需要具备的基础是：了解 Java 基础语法和 Spring Boot 的基本概念，接触过微信小程序开发工具，知道什么是 MySQL 数据库。如果你完全零基础，也不影响阅读，遇到不熟悉的术语时，我会先用通俗方式解释一遍。

2. 系统整体功能设计与技术选型

2.1 健身房管理系统的核心需求

在正式写代码之前，我们先把业务场景梳理清楚。一个典型的健身房管理系统，参与角色主要有三类：到店健身的会员、提供课程服务的教练、负责整体运营的管理员。

从会员角度看，他们最关心的是三件事：

查看今天有哪些团课或私教课。
选择合适的时间预约课程。
查看自己的预约记录、会员卡剩余天数。

从教练角度看，他们需要知道自己每天有几节课、在哪个时间段上课、有哪些学员约了自己的课。

从管理员角度看，他们需要维护课程信息、安排教练排班、管理会员卡类型、统计每日预约数据。

如果用一句话概括系统的核心逻辑，那就是：课程是资源，预约是状态流转，会员卡是权限凭证。所有功能设计都应该围绕这三个要素展开。

2.2 原生小程序还是 uniapp？

这是很多人在技术选型阶段就会卡住的问题。原生微信小程序使用 WXML + WXSS + JS/TS，由微信开发者工具直接编译运行，调试方便，API 调用直接；uniapp 则是 Vue 语法跨端开发，一套代码可以同时发布到微信小程序、App、H5 等多个平台。

对于健身房管理系统这类以课程设计和毕业设计为主的单体项目，更推荐直接使用原生微信小程序开发。理由是：

项目功能聚焦在微信生态内，不需要考虑“多端复用”这种需求。
原生开发遇到问题时，网上可参考的代码和社区讨论最多。
微信开发者工具对原生项目的调试体验最好，特别适合边写边调样式。

如果你的目标是做一套可以同时覆盖微信公众号 H5 和企业微信端的系统，再考虑 uniapp 也不迟。简单说，项目范围决定技术选型，不要为了“听起来高级”而增加不必要的复杂度。

2.3 后端技术方案选择

后端方面，本系统采用Spring Boot + MyBatis-Plus + MySQL的组合。Spring Boot 的自动配置能力能极大减少项目搭建成本，MyBatis-Plus 可以避免写大量重复的 CRUD SQL，MySQL 则完全能支撑健身房管理系统这一体量的数据存储需求。

在实际项目中，后端接口通常按照以下方式组织：

模块	功能描述	主要接口
用户模块	微信登录、会员信息维护	`/api/user/login`、`/api/user/info`
课程模块	课程列表、课程详情	`/api/course/list`、`/api/course/detail`
教练模块	教练列表、教练详情	`/api/coach/list`
预约模块	创建预约、取消预约、记录查询	`/api/booking/create`、`/api/booking/cancel`
后台管理	课程管理、教练排班、数据统计	`/api/admin/course`、`/api/admin/stats`

3. 数据库设计与核心表结构

3.1 数据表关系梳理

健身房的业务逻辑并不复杂，但数据表之间的关系必须提前理清楚。下面这个关系链是系统设计的基础：

一个会员可以有多条预约记录。
一个教练可以负责多个课程时段。
一个课程时段可以被多个会员预约，但名额有限。
会员卡决定会员是否有权限预约课程。

基于这个关系，可以设计出四张核心表：会员表、教练表、课程表、预约表。如果再扩展会员卡类型、订单支付、系统管理员等模块，可以继续增加对应表。

3.2 核心表 DDL 参考

下面是项目中最重要的四张表的建表 SQL。

-- 会员表 CREATE TABLE `member` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键ID', `openid` VARCHAR(64) NOT NULL COMMENT '微信openid', `nickname` VARCHAR(64) DEFAULT '' COMMENT '会员昵称', `avatar_url` VARCHAR(255) DEFAULT '' COMMENT '会员头像', `phone` VARCHAR(20) DEFAULT '' COMMENT '手机号', `card_type` TINYINT DEFAULT 0 COMMENT '会员卡类型 0-无 1-月卡 2-季卡 3-年卡', `card_expire_time` DATETIME DEFAULT NULL COMMENT '会员卡到期时间', `status` TINYINT DEFAULT 1 COMMENT '状态 1-正常 0-禁用', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_openid` (`openid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='会员表';

-- 教练表 CREATE TABLE `coach` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键ID', `name` VARCHAR(32) NOT NULL COMMENT '教练姓名', `avatar_url` VARCHAR(255) DEFAULT '' COMMENT '头像', `title` VARCHAR(64) DEFAULT '' COMMENT '职称，如高级私教', `intro` VARCHAR(500) DEFAULT '' COMMENT '个人简介', `status` TINYINT DEFAULT 1 COMMENT '状态 1-在职 0-离职', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='教练表';

-- 课程表 CREATE TABLE `course` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键ID', `name` VARCHAR(64) NOT NULL COMMENT '课程名称', `coach_id` BIGINT NOT NULL COMMENT '教练ID', `course_date` DATE NOT NULL COMMENT '上课日期', `start_time` TIME NOT NULL COMMENT '开始时间', `end_time` TIME NOT NULL COMMENT '结束时间', `max_count` INT DEFAULT 10 COMMENT '最大人数', `booked_count` INT DEFAULT 0 COMMENT '已预约人数', `status` TINYINT DEFAULT 1 COMMENT '状态 1-可预约 0-已关闭 2-已结束', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课程表';

-- 预约表 CREATE TABLE `booking` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键ID', `member_id` BIGINT NOT NULL COMMENT '会员ID', `course_id` BIGINT NOT NULL COMMENT '课程ID', `status` TINYINT DEFAULT 1 COMMENT '状态 1-已预约 2-已取消 3-已完成', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`), KEY `idx_member_id` (`member_id`), KEY `idx_course_id` (`course_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='预约表';

说明一下几个设计细节：

会员表用openid做唯一索引，这是微信小程序登录体系的关键字段，一个微信号对应一个 openid。
课程表同时存储了max_count和booked_count，预约时可以先用booked_count < max_count做条件更新，避免超卖。
预约表通过member_id和course_id关联会员与课程，状态字段记录整个预约的生命周期。

这套表结构不复杂，但已经能覆盖“会员管理、教练管理、课程预约、取消预约、历史记录”五个核心功能。

4. 环境准备与微信小程序前置配置

4.1 注册小程序账号

开发微信小程序的第一步，是到微信公众平台注册一个小程序账号。个人主体可以注册，但个人主体的小程序不能开通微信支付，部分接口的权限也会受限。如果课程设计或毕业设计只需要演示预约流程，个人主体足够；如果要完整对接微信支付，则需要企业主体的小程序。

注册完成后，在“开发管理 - 开发设置”页面可以拿到AppID。这个 ID 在创建小程序项目时会用到。注意区分AppID和AppSecret，后者是后端调用微信接口时用的密钥，一定不要暴露在小程序前端代码里。

4.2 安装开发工具

微信官方提供的“微信开发者工具”是开发调试小程序的主要工具，直接到官网下载对应操作系统的稳定版即可。工具支持模拟器预览、真机调试、代码上传等能力，对于课程设计来说，一个开发者工具加一个文本编辑器就已经足够。

后端开发环境方面，需要提前安装：

JDK 1.8 及以上版本。
Maven 3.6 以上版本。
MySQL 5.7 或 8.0。
IDEA 或 Eclipse（任选其一）。

版本号不用追求最新，以稳定为主。实际项目部署时，大多数高校实验室和服务器环境仍然是 JDK 8 + MySQL 5.7 的组合，代码遵循这个基线，兼容性最好。

4.3 小程序后台的基本配置

在小程序后台需要完成以下几项基础配置：

在“开发管理 - 开发设置 - 服务器域名”中，配置request合法域名。小程序的wx.request只能请求已经备案并配置过的 HTTPS 域名，不能直接请求本地 IP。
如果需要发送订阅消息，需要先在“功能 - 订阅消息”中选用消息模板。
开发调试阶段，可以在微信开发者工具中勾选“不校验合法域名…”，这样就能请求本地后端接口。

这里的核心认知是：小程序前端代码运行在微信的容器里，网络请求有着严格的域名白名单限制。开发阶段可以使用跳过校验，但真实上线前必须配置正式域名，否则真机预览会直接报url not in domain list。

5. 核心功能完整实现

5.1 微信登录与用户信息获取

小程序端用户点击“微信一键登录”时，并不会直接把自己的微信账号密码传给后端。正确的流程是：

小程序端调用wx.login()获取临时凭证code。
后端拿着code调用微信的code2Session接口，换取openid。
后端根据openid创建或查询会员记录，返回自定义登录态（比如 JWT token）。
小程序端把 token 保存起来，后续请求统一携带。

这里最容易踩坑的地方是：小程序端不能直接拿着code去请求微信接口换取 openid，因为请求过程中需要用到AppSecret，这个密钥一旦出现在前端代码里，任何人都能通过抓包获取，账号安全直接崩溃。所以code2Session的调用必须放在后端完成。

下面是后端 Controller 层处理登录的 Java 代码示例。

// 文件路径：src/main/java/com/gym/controller/AuthController.java @RestController @RequestMapping("/api/user") public class AuthController { @Autowired private UserService userService; @PostMapping("/login") public Result<String> login(@RequestBody LoginRequest request) { // 1. 调用微信 code2Session 接口，获取 openid String openid = userService.code2Session(request.getCode()); // 2. 根据 openid 查询会员，不存在则自动注册 Member member = userService.loginOrRegister(openid); // 3. 生成自定义登录态 token String token = userService.generateToken(member.getId()); return Result.success(token); } }

核心逻辑都在UserService里，重点看code2Session的实现：

// 文件路径：src/main/java/com/gym/service/impl/UserServiceImpl.java public String code2Session(String code) { // 使用 HttpClient 请求微信接口 String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appid + "&secret=" + secret + "&js_code=" + code + "&grant_type=authorization_code"; String result = HttpClientUtil.doGet(url); JSONObject json = JSON.parseObject(result); if (json.get("errcode") != null) { throw new BusinessException("微信登录失败：" + json.getString("errmsg")); } return json.getString("openid"); }

微信返回的openid是用户在当前小程序下的唯一标识。同一个用户在不同小程序里，openid 是不同的。后续所有涉及用户身份的操作，都应该基于openid对应的会员表中记录来完成。

关于用户昵称和头像，现在微信已经调整了规则，wx.getUserProfile和wx.getUserInfo不再是获取头像昵称的推荐方式。官方推荐用户主动点击“头像昵称填写”组件，由用户自行填写昵称、选择头像。这个变化在开发课程设计时要特别注意，否则会出现“真机调试时拿不到用户信息”的诡异问题。

小程序端获取登录code并携带 token 请求用户信息的代码如下：

// 文件路径：pages/login/login.js Page({ data: { nickname: '', avatarUrl: '' }, onLogin() { wx.login({ success: (res) => { if (res.code) { wx.request({ url: 'https://your-domain.com/api/user/login', method: 'POST', data: { code: res.code }, success: (resp) => { const token = resp.data.data; wx.setStorageSync('token', token); wx.switchTab({ url: '/pages/index/index' }); } }); } } }); } });

5.2 课程列表展示

课程首页是用户打开小程序后看到的第一个核心页面。它需要展示课程名称、教练、时间、剩余名额等基础信息。这部分虽然以展示为主，但有一个关键设计：预约名额是实时变化的，不能把剩余名额写死在前端，必须通过接口实时查询。

一个最简单的课程列表接口如下：

// 文件路径：src/main/java/com/gym/controller/CourseController.java @RestController @RequestMapping("/api/course") public class CourseController { @Autowired private CourseService courseService; @GetMapping("/list") public Result<List<CourseVO>> list(@RequestParam(required = false) String date) { List<CourseVO> list = courseService.getCourseList(date); return Result.success(list); } }

CourseVO是一个视图对象，它的作用是把数据库里的course表字段和前端需要展示的字段做一次转换。比如数据库里coach_id是数字，但前端要展示教练姓名，这就需要通过关联查询把教练姓名填充到coachName字段里，而不是直接把coach_id丢给前端。

public List<CourseVO> getCourseList(String date) { LambdaQueryWrapper<Course> wrapper = new LambdaQueryWrapper<>(); wrapper.ge(Course::getCourseDate, LocalDate.now()) .orderByAsc(Course::getCourseDate) .orderByAsc(Course::getStartTime); if (StringUtils.hasText(date)) { wrapper.eq(Course::getCourseDate, LocalDate.parse(date)); } List<Course> courses = courseMapper.selectList(wrapper); List<CourseVO> result = new ArrayList<>(); for (Course course : courses) { Coach coach = coachMapper.selectById(course.getCoachId()); CourseVO vo = new CourseVO(); BeanUtils.copyProperties(course, vo); vo.setCoachName(coach != null ? coach.getName() : ""); vo.setCoachAvatar(coach != null ? coach.getAvatarUrl() : ""); result.add(vo); } return result; }

这里用到了 MyBatis-Plus 的LambdaQueryWrapper，它解决的核心痛点是：不用手写 SQL，而是通过 Java 方法引用来描述查询条件，既避免了拼 SQL 时容易出现的单引号问题，也让代码在编译期就有类型检查。

小程序端课程列表页的请求封装可以统一放在utils/request.js中，避免每个页面重复写wx.request：

// 文件路径：utils/request.js const BASE_URL = 'https://your-domain.com/api'; function request(url, method = 'GET', data = {}) { return new Promise((resolve, reject) => { const token = wx.getStorageSync('token'); wx.request({ url: BASE_URL + url, method: method, data: data, header: { 'Content-Type': 'application/json', 'Authorization': token ? 'Bearer ' + token : '' }, success: (res) => { if (res.statusCode === 200 && res.data.code === 0) { resolve(res.data.data); } else if (res.statusCode === 401) { wx.navigateTo({ url: '/pages/login/login' }); } else { wx.showToast({ title: res.data.msg || '请求失败', icon: 'none' }); reject(res); } }, fail: (err) => { wx.showToast({ title: '网络异常', icon: 'none' }); reject(err); } }); }); } module.exports = { request, BASE_URL };

需要注意，request封装里的BASE_URL必须要改成用户自己的域名。课程设计答辩时，很多同学就是因为忘了改这个地址，导致演示环节小程序全部请求失败，整体体验大打折扣。

5.3 预约与防超卖逻辑

预约功能是整套系统的核心。用户在课程详情页点击“立即预约”后，后端不仅要做“插入一条预约记录”，还要做三件非常重要的事：

校验会员卡是否有效。
校验该会员是否已预约同一时段课程。
扣减课程的可预约名额。

这三步必须放在同一个数据库事务里执行，不能分开。如果先插入了预约记录、再扣减名额，中途一旦出现异常，会出现“预约记录存在但名额没有减少”的脏数据。

下面是一个带事务控制和乐观锁防超卖的实现：

// 文件路径：src/main/java/com/gym/service/impl/BookingServiceImpl.java @Transactional(rollbackFor = Exception.class) public void createBooking(Long memberId, Long courseId) { // 1. 查询课程信息，课程不存在直接报错 Course course = courseMapper.selectById(courseId); if (course == null) { throw new BusinessException("课程不存在"); } // 2. 校验会员卡有效期 Member member = memberMapper.selectById(memberId); if (member.getCardExpireTime() == null || member.getCardExpireTime().isBefore(LocalDateTime.now())) { throw new BusinessException("会员卡已过期，请续费后再预约"); } // 3. 校验是否重复预约 LambdaQueryWrapper<Booking> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Booking::getMemberId, memberId) .eq(Booking::getCourseId, courseId) .eq(Booking::getStatus, 1); List<Booking> list = bookingMapper.selectList(wrapper); if (!list.isEmpty()) { throw new BusinessException("您已预约过该课程"); } // 4. 通过条件更新扣减名额，防止超卖 int rows = courseMapper.reduceBookedCount(courseId); if (rows == 0) { throw new BusinessException("课程名额已满"); } // 5. 创建预约记录 Booking booking = new Booking(); booking.setMemberId(memberId); booking.setCourseId(courseId); booking.setStatus(1); bookingMapper.insert(booking); }

其中最关键的是第 4 步，对应的 SQL 如下：

UPDATE course SET booked_count = booked_count + 1 WHERE id = #{courseId} AND booked_count < max_count

这个 SQL 的巧妙之处在于：它把“检查名额”和“扣减名额”合并成了一个原子操作。数据库行锁保证了并发场景下不会出现两个用户同时把最后一个名额约走的情况。如果受影响行数为 0，说明课程已经满员。

为了更直观地展示预约接口返回，这里给出小程序端预约请求的代码示例：

// 文件路径：pages/course-detail/course-detail.js const { request } = require('../../utils/request'); Page({ data: { course: null, loading: false }, onLoad(options) { const id = options.id; this.loadCourseDetail(id); }, loadCourseDetail(id) { request(`/course/detail?id=${id}`).then((data) => { this.setData({ course: data }); }); }, onBooking() { if (this.data.loading) return; const course = this.data.course; if (!course || course.status !== 1) { wx.showToast({ title: '当前课程不可预约', icon: 'none' }); return; } this.setData({ loading: true }); request('/booking/create', 'POST', { courseId: course.id }) .then(() => { wx.showToast({ title: '预约成功', icon: 'success' }); this.loadCourseDetail(course.id); }) .finally(() => { this.setData({ loading: false }); }); } });

这里的防重复点击处理同样重要。用户在快速点击两次“立即预约”按钮时，如果前端不做loading拦截，会发出两个相同的请求，后端虽然可以通过数据库校验挡住重复预约，但还是会浪费一次网络开销，也会让用户的体验变差。

5.4 订阅消息通知

用户预约课程后，最理想的效果是在上课前一天收到一条“课程提醒”通知。微信小程序要实现这个能力，使用订阅消息机制。但这里有一个必须了解的限制：订阅消息只能通过用户主动点击授权触发，不能由后端任意推送给用户。

也就是说，用户点击“预约”按钮的同时，小程序端需要弹出订阅消息授权框，用户点击“允许”后，后端才能在下一次向这个用户发送一条订阅消息。而且一次性订阅消息只能用一次，用户没点授权，消息就发不出去。

真实项目中的做法一般是：

预约时同步请求订阅消息授权。
授权成功后，把用户 id 和消息场景记录下来。
到时间后，后端调用微信的subscribeMessage.send接口发送提醒。

小程序端请求授权的代码：

wx.requestSubscribeMessage({ tmplIds: ['你的模板ID'], success(res) { if (res['你的模板ID'] === 'accept') { console.log('用户允许订阅'); } } });

后端发送订阅消息的 Java 代码，可以参考下面这个实现。需要先通过 access_token 获取发送凭证，再通过 HTTP 请求调用微信接口：

public void sendSubscribeMessage(String openid, String courseName, String startTime) { String accessToken = getAccessToken(); String url = "https://api.weixin.qq.com/cgi-bin/message/subscribe/send?access_token=" + accessToken; JSONObject data = new JSONObject(); data.put("touser", openid); data.put("template_id", "你的模板ID"); data.put("page", "pages/course-detail/course-detail"); JSONObject messageData = new JSONObject(); JSONObject course = new JSONObject(); course.put("value", courseName); messageData.put("thing1", course); JSONObject time = new JSONObject(); time.put("value", startTime); messageData.put("time2", time); data.put("data", messageData); String result = HttpClientUtil.doPostJson(url, data.toJSONString()); JSONObject resultJson = JSON.parseObject(result); if (resultJson.getIntValue("errcode") != 0) { log.error("发送订阅消息失败：{}", result); } }

订阅消息的模板ID和字段key都需要在微信公众平台后台申请。不同模板的字段名不一样，比如thing1、time2这种编号，完全取决于你选用的是哪个消息模板。写代码前一定要先在后台确认字段对应的 key，否则发送时会出现 “data field is incorrect” 之类的报错。

5.5 微信支付接入的思考

课程设计和毕业设计阶段，经常会有同学想加上“在线购买会员卡”功能，这就涉及微信支付。先说结论：这一步在个人主体的公众号和小程序里是做不了的，必须使用企业主体，并且完成微信商户号申请。

微信支付 v3 对接的逻辑链路大致是：

小程序端调用wx.requestPayment发起支付。
后端调用微信支付统一下单接口，生成预支付订单。
微信返回prepay_id，后端进行二次签名，返回给小程序端。
小程序调起支付收银台，用户输入密码完成支付。
微信服务器异步通知后端支付结果，后端更新订单状态。

真正容易出问题的地方集中在两处。第一是商户证书的配置，apiclient_key.pem、apiclient_cert.pem这些文件不要搞混；第二是回调地址必须是公网可访问的 HTTPS 地址，本地开发时可以用内网穿透工具调试，但生产环境建议直接用云服务器配置。

下面是基于微信官方 Java SDK 的统一下单核心代码：

// 文件路径：src/main/java/com/gym/service/impl/PayServiceImpl.java public String unifiedOrder(Long memberId, Integer amount, String description) throws Exception { // 1. 构建请求参数 String outTradeNo = "G" + System.currentTimeMillis(); String notifyUrl = "https://your-domain.com/api/pay/notify"; RequestParam param = new RequestParam.Builder() .setAppid(appid) .setMchid(mchId) .setDescription(description) .setOutTradeNo(outTradeNo) .setNotifyUrl(notifyUrl) .setAmount(new Amount().setTotal(amount)) .build(); TransactionsResult result = payService.getPayService().transactions() .create(param); return result.getPrepayId(); }

这里要特别提醒：支付涉及资金安全，代码写完后必须有足够的测试验证，而且不能拿正式商户号做随意测试。课程设计如果只是想演示功能流程，可以只保存订单数据，把“支付成功”状态通过模拟接口完成，重点展示预约、会员卡管理等核心业务逻辑。这样既避免踩合规与安全红线，也能把精力放在更有技术含量的模块上。

6. 管理员后台功能设计与实现

6.1 后台的定位

小程序端面向用户，管理员后台面向运营者。后台界面可以用一个简单的 Web 页面实现，也可以直接复用小程序端，做一个“管理员角色 + 隐藏入口”的设计。对于课程设计来说，后者的成本更低，但前者的展示效果更完整，也更接近真实项目。

如果选择独立 Web 后台，推荐使用 Vue 3 + Element Plus 这样的组合。后端接口可以继续复用 Spring Boot，只需要增加一组/api/admin前缀的接口，并对管理员身份做权限校验。

6.2 后台核心功能

后台涉及的功能至少包括以下四类：

课程管理：新增课程、修改课程时间、关闭满员课程。
教练管理：录入教练信息、设置教练可授课时段。
会员管理：查看所有会员、手动调整会员卡到期时间。
数据统计：按日/按周统计预约数量、课程满员率。

课程安排的冲突检测是后台开发的难点。一个教练不能同时上两节课，所以新增课程时要校验教练的course_date + start_time + end_time是否与已有课程重叠。这需要在数据库查询时做时间段交叉判断：

public void checkCoachConflict(Long coachId, LocalDate courseDate, LocalTime startTime, LocalTime endTime) { LambdaQueryWrapper<Course> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Course::getCoachId, coachId) .eq(Course::getCourseDate, courseDate) .and(w -> w.lt(Course::getStartTime, endTime) .gt(Course::getEndTime, startTime)); List<Course> conflictList = courseMapper.selectList(wrapper); if (!conflictList.isEmpty()) { throw new BusinessException("该教练在当前时间段已有课程安排"); } }

这段代码的核心原理是时间段重叠判断。如果新课程的startTime小于已有课程的endTime，并且新课程的endTime大于已有课程的startTime，说明两个时间段存在交叉。用简单的lt和gt条件组合就能完成冲突检测。

6.3 数据统计的极简方案

“统计”听起来复杂，但如果只是统计课程预约人数，并不需要引入大而全的数据分析框架。一条 SQL 就能完成最常见的统计需求：

SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS day, COUNT(*) AS booking_count FROM booking WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE_FORMAT(create_time, '%Y-%m-%d') ORDER BY day;

这条 SQL 返回最近七天每天的预约数量，用于后台的折线图展示已经足够。统计模块的核心原则是：先用最简单的查询满足 80% 的需求，不要为了一个课程设计引入 Hadoop、Spark 这类重型组件。

7. 系统联调与运行验证

7.1 后端启动验证

先确认 Spring Boot 项目能正常启动。在项目根目录执行：

mvn spring-boot:run

启动成功的标志是控制台打印出类似Started Application in x seconds的日志。如果出现APPLICATION FAILED TO START，优先检查数据库连接配置，特别要确认application.yml中的数据库地址、账号、密码是否与本地环境一致。

# 文件路径：src/main/resources/application.yml server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/gym_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

serverTimezone这个参数非常容易忽略。如果不设置，在高版本 MySQL 连接时会报时区错误。使用Asia/Shanghai可以避免因默认时区导致的 8 小时时间偏移问题。

7.2 小程序端运行验证

第一步，用微信开发者工具导入创建好的小程序项目，填上自己的AppID。

第二步，在开发者工具的“详情 - 本地设置”中勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”。

第三步，在utils/request.js中把BASE_URL改成自己电脑局域网 IP 加端口，例如http://192.168.1.100:8080/api，同时确保手机和电脑连接的是同一个 Wi-Fi。

第四步，点击编译，模拟器会展示小程序首页。如果课程列表接口正常，首页会展示在数据库中创建的测试课程数据。

真机调试时最诡异的问题是：模拟器里能请求到数据，真机一打开就白屏。这类问题 99% 是域名配置问题或后端接口地址不可从外网访问。开发阶段调试真机时，建议直接用微信开发者工具自带的“真机调试”功能，它会在手机和电脑之间建立一条调试通道，局域网请求也能正常工作。

7.3 功能测试清单

上线前或答辩前，建议按下面这个清单逐项过一遍：

[ ] 全新用户首次登录，能否自动注册并正常返回 token。
[ ] 课程列表能否按日期筛选。
[ ] 用户预约成功后，是否有防重复预约提示。
[ ] 满员课程再次预约时，是否返回“名额已满”。
[ ] 取消预约后，课程数量是否回退。
[ ] 管理员新增课程时，教练冲突时段是否被拦截。
[ ] 后台数据统计是否能返回最近七天的预约曲线。

8. 常见问题与排查思路

下面汇总了健身房管理系统开发中最典型的几个问题，每一组都给出了现象、原因和解决方案。

问题现象	可能原因	排查方式	解决方案
小程序端请求接口报`url not in domain list`	未配置合法域名，或本地开发未跳过域名校验	在开发者工具中勾选“不校验合法域名”	正式上线必须配置 HTTPS 合法域名
真机可以登录但`wx.login`返回的 code 无效	AppID 与 AppSecret 不匹配	检查后端`application.yml`中的 appid 和 secret	到微信公众平台确认 AppID 和 AppSecret 是否一致
用户点击预约后提示“您已预约过该课程”	数据库中存在相同 member_id 和 course_id 的记录	查询 booking 表确认预约记录	检查预约接口是否被重复点击调用
课程名额扣减异常或出现负数	SQL 没有使用条件更新，导致并发下数据不一致	检查 reduceBookedCount 方法 SQL	改为`UPDATE course SET booked_count = booked_count + 1 WHERE booked_count < max_count`
微信支付回调验签失败	API v3 密钥配置错误或回调参数读取方式不对	检查请求头中的签名信息，对比商户平台配置	先使用微信提供的 SDK 工具做验签，不要自己手写验签逻辑
小程序真机调试时 video 组件无法播放或全屏错位	组件层级问题或同层渲染异常	检查是否使用了 cover-view 包裹 video	优先使用原生组件层级配置，必要时升级基础库版本
自定义导航栏在 iOS 上状态栏高度不对	未适配安全区	在 app.json 中设置自定义导航栏后，手动计算状态栏高度	使用`wx.getSystemInfoSync()`获取 statusBarHeight 并动态计算
手机软键盘遮挡输入框内容	页面底部输入框被键盘顶起	在页面配置中开启`adjust-position`	监听`onKeyboardHeightChange`动态调整页面高度

// 解决 iOS 自定义导航栏状态栏高度问题 const systemInfo = wx.getSystemInfoSync(); Page({ data: { statusBarHeight: systemInfo.statusBarHeight } });

9. 最佳实践与工程建议

9.1 不要把所有字段都返回给前端

课程列表接口，不要把course表的全部字段直接作为 JSON 返回。例如booked_count是数据库维护的字段，前端只需要显示“剩余名额”，那就可以在视图对象里计算好remainCount，再返回给前端。这样后端接口的语义更清晰，也能减少前端处理数据的负担。

9.2 数据库统一使用 utf8mb4

utf8mb4是utf8的超集，能完整支持 emoji 表情和一些特殊字符。用户昵称里如果带有表情符号，使用老旧的utf8编码会导致插入数据库报错。这是课程设计中最容易遇到却又最难排查的问题之一，因为开发者本地往往是英文字符，完全不会触发。

9.3 预约状态不要在前端维护

预约状态是一个典型的状态机。初始是“已预约”，用户取消后变成“已取消”，课程时间过了之后由定时任务或查询时动态计算为“已完成”。最简单的方式是查询时根据start_time < NOW()自动判定历史预约，不要单独写一套定时任务去批量更新，除非系统规模足够大。

9.4 接口幂等性设计

凡是涉及“创建预约”“生成订单”这种写操作，都应该考虑幂等。最简单的方式是前端在请求时生成一个唯一请求号（比如requestId），后端先查这个请求号是否处理过，再决定是否继续执行业务逻辑。课程设计阶段不一定需要实现完整的幂等框架，但至少要在预约接口里加上重复数据校验。

9.5 上线前的安全检查

小程序上线前需要重点核对以下几项：

AppSecret是否泄露到前端代码中。
后端接口是否做了鉴权，未登录用户能否直接调用预约接口。
HTTPS 证书是否配置正确。
数据库连接密码是否使用了弱口令。
是否有测试数据污染正式环境。

9.6 关于代码版本管理

写课程设计或毕业设计时，建议从第一天就使用 Git 做版本管理。哪怕是单人项目，Git 也能让你随时回退到可运行的状态。不要等代码写到一半崩了才想起没有备份，这种教训在开发中太常见了。

10. 总结与后续学习方向

这篇文章围绕“基于微信小程序健身房管理系统”展开了从设计到落地的完整过程。你可以看到，一套小体量的管理系统虽然功能边界有限，但它涵盖的技术点却很完整：用户登录态的建立、数据库表的合理设计、事务控制下的并发防超卖逻辑、微信生态内特有的订阅消息配置、以及支付接入时的合规边界。

真正值得你花时间掌握的，不是某一个页面的样式，而是三个成体系的思考方式：

第一，状态管理。预约状态从“可预约”到“已满”再到“已完成”，每一步的流转都需要数据支撑。理解状态机的思想后，不止健身房系统，你能把外卖系统、会议室预约系统、图书馆座位管理系统里那些看似不同的业务，都归结为同一个“资源与预约”模型。

第二，事务与并发。一个简单的booked_count + 1，在单用户场景下看起来毫无问题，但在并发场景下会因为缺少行锁导致超卖。用“条件更新 + 事务控制”这套通用方案，能帮助你理解更多的并发业务问题。

第三，微信生态的边界意识。订阅消息不是想推就能推，微信支付不是想接就能接。做小程序开发，第一时间了解平台规则，比盲目写代码更重要。

如果你想进一步深入，下面这几个方向是自然的延伸路径：

把系统从单体 Spring Boot 改为前后端分离，使用 Vue 3 开发管理后台，学习接口鉴权框架（如 Sa-Token 或 Spring Security）。
引入 Redis 缓存课程列表数据，优化高并发热点数据的响应速度。
学习微信小程序的自动化测试与 CI/CD 发布流程，把项目做到“一键上传体验版”。

开发这类系统，最大的收获不是“我写完了 20 个接口”，而是“我终于知道一个看起来简单的业务逻辑，背后有多少边界条件要考虑”。建议把这篇文章收藏备用，做课程设计或答辩前再拿出来对照自查一遍，能帮你少踩很多坑。