简介本资源为基于SpringBoot与Vue的健身房会员管理系统完整源码面向计算机专业学生、Java全栈初学者及需要课程设计或毕业设计参考的开发者可帮助快速理解前后端分离架构下的业务落地方式。压缩包共1023个文件约51.67MB其中Java类文件133个承载后端业务逻辑Vue组件64个与JavaScript脚本157个构成前端交互层另有CSS、HTML、SVG图标及图片资源用于页面样式与视觉呈现并附带bat启动脚本与yml配置便于本地运行。系统区分用户、教练与管理员三类角色用户可登录注册、购买课程、兑换商品、评价收藏管理员负责教练、课程、商品、基础数据与公告管理教练可回复帖子并查看各类信息。目前已有347人学习下载适合作为全栈项目实战模板读者可从中掌握SpringBoot接口设计、Vue组件化开发、多角色权限控制及订单与论坛模块的实现思路也可直接用于二次开发或答辩演示。1. 健身房会员管理系统从一张会员卡背后的数据流说起前台小姐姐刷一下卡闸机放行手环亮起更衣柜自动分配——这套动作背后其实跑着一整条数据链路会员身份核验、会籍有效期判断、剩余次数扣减、入场记录落库。很多中小健身房还在用 Excel 加微信群管会员续卡靠翻聊天记录私教课消课靠纸质签到表月底对账能对到怀疑人生。基于 SpringBoot 和 Vue 的健身房会员管理系统要解决的就是把这条链路从「人肉维护」搬到「系统自动流转」。它适合两类人一是健身房老板或运营想搞清楚一套系统到底该管哪些事二是正在做课程设计或毕业设计的开发者需要一个业务闭环完整、技术栈主流的实战项目。源码设计与实现的核心不在于界面多花哨而在于会籍状态机、消课逻辑和并发扣次这三件事能不能扛住真实场景。2. 技术选型与数据模型为什么是 SpringBoot 加 Vue 这套组合2.1 后端选 SpringBoot 的三个现实理由健身房的业务量不大但请求类型杂会员端要查课表、约课、看剩余次数前台端要刷卡入场、续卡、请假教练端要排课、消课、看提成。这种多角色、多终端、中等并发的场景SpringBoot 的优势很直接。第一起步快。一个spring-boot-starter-web加spring-boot-starter-data-jpa或 MyBatis半天就能把会员 CRUD 跑通。第二生态全。会籍到期提醒要发短信接个 starter 就行入场记录要导出 ExcelEasyExcel 一引就有后面想加微信小程序端同一套接口直接复用。第三部署简单。打成 jar 包丢服务器上java -jar就能跑健身房没有专职运维这点很关键。我一般会选 SpringBoot 2.7.x 配 JDK 8 或 11稳定且资料多。数据库用 MySQL 8.0连接池默认 HikariCP 就够。ORM 层如果团队熟悉 SQL用 MyBatis-Plus 更顺手如果追求快速开发Spring Data JPA 也行。缓存用 Redis 存会籍状态和课表避免每次刷卡都查库。# application.yml 关键配置 spring: datasource: url: jdbc:mysql://localhost:3306/gym_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password hikari: maximum-pool-size: 10 minimum-idle: 2 redis: host: localhost port: 6379 database: 0 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这段配置里serverTimezone必须设对否则会籍到期时间会差 8 小时导致会员明明没过期却被拦在闸机外。maximum-pool-size设 10 是因为健身房并发不高设太大反而浪费连接。Redis 的database建议单独分一个库别和别的项目混用。2.2 前端选 Vue 的落地考量Vue 的核心优势是上手平缓、组件化清晰。前台收银界面、会员列表、课表日历这些页面用 Element Plus 或 Ant Design Vue 能快速搭出来。Vue 3 加 Vite 的构建速度比 Webpack 快很多改一行代码秒级热更新开发体验好。路由用 Vue Router状态管理用 Pinia。会员端和员工端可以做成两套布局通过路由守卫区分权限。比如/member/*走会员布局/admin/*走管理布局登录后根据角色跳转。// router/index.js 权限路由核心逻辑 const routes [ { path: /login, component: Login }, { path: /admin, component: AdminLayout, meta: { requiresAuth: true, role: ADMIN }, children: [ { path: members, component: MemberList }, { path: checkin, component: CheckinPanel } ] }, { path: /member, component: MemberLayout, meta: { requiresAuth: true, role: MEMBER }, children: [ { path: courses, component: CourseBooking }, { path: profile, component: MemberProfile } ] } ] router.beforeEach((to, from, next) { const token localStorage.getItem(token) const role localStorage.getItem(role) if (to.meta.requiresAuth !token) { next(/login) } else if (to.meta.role to.meta.role ! role) { next(/login) } else { next() } })路由守卫里meta.role做角色隔离防止会员通过改 URL 访问管理页面。localStorage存 token 是常见做法但要注意 XSS 风险后面避坑章节会讲。2.3 数据模型五张核心表撑起业务闭环健身房的业务说复杂也复杂说简单也简单。核心就五张表会员表、会籍卡表、课程表、预约记录表、入场记录表。表名关键字段说明memberid, name, phone, gender, status会员基本信息status 区分正常/冻结/过期membership_cardid, member_id, type, start_date, end_date, remaining_times, status会籍卡type 区分年卡/次卡/私教课包courseid, name, coach_id, schedule_time, capacity, booked_count课程capacity 和 booked_count 控制约课人数bookingid, member_id, course_id, status, create_time预约记录status 区分已约/已消/已取消checkinid, member_id, checkin_time, device_id入场记录device_id 对应闸机编号会员表和会籍卡表是一对多一个会员可以有多张卡年卡到期后续次卡。预约记录表要加唯一索引(member_id, course_id)防止重复约课。入场记录表按时间分区数据量大了查询才不慢。3. 核心功能实现从刷卡入场到消课扣次的完整链路3.1 刷卡入场会籍状态校验与并发扣次刷卡入场是整个系统最高频的操作也是最容易出问题的地方。流程是闸机读卡号 → 后端查会员 → 校验会籍状态 → 扣减次数 → 写入场记录 → 返回放行指令。// CheckinService.java 核心逻辑 Transactional public CheckinResult checkin(String cardNo, String deviceId) { // 1. 查会员 Member member memberMapper.selectByCardNo(cardNo); if (member null) { return CheckinResult.fail(卡号不存在); } // 2. 查有效会籍卡 MembershipCard card cardMapper.selectValidCard(member.getId()); if (card null) { return CheckinResult.fail(无有效会籍); } // 3. 校验有效期 if (card.getEndDate().before(new Date())) { return CheckinResult.fail(会籍已过期); } // 4. 次卡扣次年卡不限次则跳过 if (TIMES.equals(card.getType())) { int updated cardMapper.decrementTimes(card.getId()); if (updated 0) { return CheckinResult.fail(剩余次数不足); } } // 5. 写入场记录 Checkin record new Checkin(); record.setMemberId(member.getId()); record.setCheckinTime(new Date()); record.setDeviceId(deviceId); checkinMapper.insert(record); return CheckinResult.success(member.getName()); }这里最关键的是第 4 步的decrementTimes必须用 SQL 的原子操作不能先查再减。-- MembershipCardMapper.xml UPDATE membership_card SET remaining_times remaining_times - 1 WHERE id #{cardId} AND remaining_times 0AND remaining_times 0是防超扣的关键。如果两个闸机同时刷同一张次卡数据库行锁会保证只有一个更新成功另一个返回 0 行受影响代码里判断updated 0就拒绝入场。这就是为什么不能用「先 select 再 update」——中间有时间窗口并发下必然翻车。注意Transactional要加在 public 方法上且调用方不能是同类内部调用否则事务不生效。这是 Spring AOP 代理的经典坑。3.2 课程预约容量控制与重复预约拦截约课的逻辑比入场复杂一点因为涉及课程容量和取消规则。会员在小程序或 App 上看到课表点预约后端要判断课程是否还有名额、会员是否已经约过、会员会籍是否有效、是否在可取消时间内。// BookingService.java Transactional public BookingResult bookCourse(Long memberId, Long courseId) { // 1. 校验会籍 MembershipCard card cardMapper.selectValidCard(memberId); if (card null) { return BookingResult.fail(会籍无效); } // 2. 查课程 Course course courseMapper.selectById(courseId); if (course null || course.getScheduleTime().before(new Date())) { return BookingResult.fail(课程不存在或已开始); } // 3. 原子占位 int updated courseMapper.incrementBooked(courseId); if (updated 0) { return BookingResult.fail(课程已满); } // 4. 写预约记录唯一索引兜底 try { Booking booking new Booking(); booking.setMemberId(memberId); booking.setCourseId(courseId); booking.setStatus(BOOKED); booking.setCreateTime(new Date()); bookingMapper.insert(booking); } catch (DuplicateKeyException e) { // 唯一索引冲突回滚占位 courseMapper.decrementBooked(courseId); return BookingResult.fail(请勿重复预约); } return BookingResult.success(); }incrementBooked的 SQL 同样要带条件UPDATE course SET booked_count booked_count 1 WHERE id #{courseId} AND booked_count capacity这样即使 100 个人同时抢 20 个名额也只有 20 个能更新成功。第 4 步的唯一索引(member_id, course_id)是第二道防线防止同一会员用不同设备重复提交。捕获DuplicateKeyException后要手动回滚占位否则名额会被白白占用。3.3 消课与提成教练端的数据闭环私教课消课是健身房的收入核心。会员上完课教练在 App 上点「消课」系统要扣减会员的私教课包次数同时记录教练的课时和提成。// CourseConsumeService.java Transactional public void consumeCourse(Long bookingId, Long coachId) { Booking booking bookingMapper.selectById(bookingId); if (booking null || !BOOKED.equals(booking.getStatus())) { throw new BizException(预约状态异常); } // 1. 更新预约状态 booking.setStatus(CONSUMED); booking.setConsumeTime(new Date()); bookingMapper.updateById(booking); // 2. 扣减私教课包次数 int updated cardMapper.decrementPrivateTimes(booking.getMemberId()); if (updated 0) { throw new BizException(私教次数不足); } // 3. 记录教练课时 CoachRecord record new CoachRecord(); record.setCoachId(coachId); record.setMemberId(booking.getMemberId()); record.setCourseId(booking.getCourseId()); record.setConsumeTime(new Date()); coachRecordMapper.insert(record); }这里的事务边界要覆盖三步操作任何一步失败都回滚。decrementPrivateTimes同样用原子 SQL条件里带remaining_private_times 0。教练提成可以在CoachRecord插入后异步计算避免拖慢消课响应。4. 避坑与排查那些让我加班到凌晨的坑4.1 会籍到期时间差 8 小时现象会员明明还有一天到期系统却提示已过期前台和会员吵起来。原因MySQL 连接串没设serverTimezone或者设成了 UTCJava 的new Date()是东八区时间存进库变成 UTC取出来再比较就差了 8 小时。解决连接串加serverTimezoneAsia/Shanghai同时application.yml里 Jackson 的time-zone也设成GMT8。如果已经上线写个脚本把历史数据的时间字段统一加 8 小时修正。4.2 并发刷卡导致次数扣成负数现象会员次卡剩 1 次两个闸机同时刷结果扣成了 -1会员要求赔偿。原因用了「先查剩余次数再 update 减一」的写法两个线程都查到 1都执行 update变成 -1。解决改成原子 SQLUPDATE ... SET remaining_times remaining_times - 1 WHERE id ? AND remaining_times 0判断受影响行数。这个坑我踩过两次血泪经验就是凡是扣减类操作一律用原子 SQL别在 Java 里做判断。4.3 前端 token 过期后页面白屏现象会员用着用着突然白屏刷新也没用清缓存才能恢复。原因token 过期后接口返回 401前端 axios 拦截器没处理路由守卫又放行了导致页面组件拿不到数据直接报错。解决在 axios 响应拦截器里统一处理 401清除本地 token 并跳转登录页。// axios 拦截器 axios.interceptors.response.use( response response, error { if (error.response error.response.status 401) { localStorage.removeItem(token) localStorage.removeItem(role) window.location.href /login } return Promise.reject(error) } )4.4 课程容量超卖现象20 人的课约到了 22 个人教练投诉。原因incrementBooked没加booked_count capacity条件或者加了但没判断受影响行数。解决SQL 必须带条件Java 里判断updated 0就返回「已满」。另外capacity字段别用int默认 0新建课程时要强制填。4.5 入场记录表查询越来越慢现象系统跑了半年前台查会员入场记录要等 5 秒以上。原因checkin表没建索引数据量到了几十万行全表扫描。解决给member_id和checkin_time建联合索引查询时带上时间范围。如果数据量继续涨按月分表或按时间分区。ALTER TABLE checkin ADD INDEX idx_member_time (member_id, checkin_time);5. 进阶技巧用状态机管会籍用定时任务做续费提醒会籍状态是这套系统里最容易写乱的地方。年卡、次卡、私教课包每种卡的状态流转不一样用 if-else 堆会越来越难维护。我一般会引入一个轻量的状态机把状态和事件定义清楚。// 会籍状态枚举 public enum CardStatus { ACTIVE, // 正常 FROZEN, // 冻结请假 EXPIRED, // 过期 USED_UP // 次数用完 } // 状态流转规则 public class CardStateMachine { public static CardStatus next(CardStatus current, String event) { switch (current) { case ACTIVE: if (FREEZE.equals(event)) return FROZEN; if (EXPIRE.equals(event)) return EXPIRED; if (USE_UP.equals(event)) return USED_UP; break; case FROZEN: if (UNFREEZE.equals(event)) return ACTIVE; break; default: return current; } return current; } }这样每次状态变更都走next方法逻辑集中在一处排查问题不用满项目搜setStatus。冻结功能对健身房很实用会员出差一个月前台点「请假」状态变 FROZEN闸机拒绝入场但到期时间顺延。续费提醒用 Spring 的Scheduled定时任务每天早上 9 点扫一遍还有 7 天到期的会员发短信或站内信。Scheduled(cron 0 0 9 * * ?) public void remindExpiringMembers() { Date sevenDaysLater DateUtils.addDays(new Date(), 7); ListMembershipCard cards cardMapper.selectExpiringBefore(sevenDaysLater); for (MembershipCard card : cards) { Member member memberMapper.selectById(card.getMemberId()); smsService.send(member.getPhone(), 您的会籍将于 DateUtils.format(card.getEndDate()) 到期请及时续费); } }cron表达式0 0 9 * * ?是每天 9 点执行。注意别在循环里查库先把会员信息批量查出来再发否则 1000 个会员就是 1000 次查询数据库扛不住。验证这套系统是否靠谱我有个习惯上线前用 JMeter 模拟 50 个并发刷卡看次数会不会扣错再用 Postman 把约课接口连点 100 次看会不会超卖。这两个测试过了基本就不会出大问题。做这类管理系统最怕的就是想当然觉得「应该不会并发」结果上线第一天就被现实教育。希望帮到你。本文还有配套的精品资源点击获取