简介这是一套面向计算机相关专业学生的健身房管理系统完整项目源码适合用作毕业设计、课程设计或期末大作业下载后无需修改即可直接运行。项目采用Java语言开发基于Idea环境与Maven构建数据库使用MySQL 5.7以上版本配合Navicat进行管理前后端代码齐全功能完善、界面美观、操作便捷具有较高的实际应用参考价值。资源包共包含521个文件整体约10.8MB其中121个Java源文件构成后端核心逻辑46个Vue组件负责前端页面交互另有大量svg图标、jpg与png图片资源、js脚本、xml配置及yml、scss样式文件并附带sql数据库脚本、功能文档与bat启动脚本目录结构清晰便于按模块查阅与二次开发。目前已有34人学习关注。对于需要快速搭建可运行项目、理解前后端分离架构与数据库设计的同学而言这份资料能提供完整的工程范例与排错参考帮助节省从零搭建的时间成本。1. 健身房管理系统设计与实现从会员刷卡到私教排课的完整闭环会员刷卡进门前台电脑上弹出他的剩余次数和到期日私教在手机端看到今天约课的会员名单老板在后台看到本月流水和续卡率——这三件事背后跑的是同一套健身房管理系统。很多中小型场馆还在用 Excel 加微信群管会员续卡提醒靠人脑记私教课时靠纸质签到月底对账对到怀疑人生。这套系统要解决的核心问题就三个会员生命周期管理、课程与私教排期、营收数据实时可见。适合谁做有 Java 或 Python Web 基础、想拿一个真实业务场景练手的开发者或者健身房老板想找人定制一套自己用的系统。下面按「需求怎么拆 → 数据库怎么设计 → 核心功能怎么实现 → 坑在哪」的路径讲清楚。2. 需求拆解与角色权限谁在什么场景下用什么功能2.1 四类角色与核心用例健身房管理系统的角色划分比通用后台复杂因为涉及线下物理场景。我一般会拆成四类角色核心操作使用终端高频场景前台会员登记、刷卡签到、续卡收费PC 浏览器高峰期每分钟处理 3-5 人教练查看排课、签到上课、查看课时费手机 H5课前 10 分钟确认名单会员查看剩余次数、预约团课、查看到期日手机 H5/小程序约课、查余额管理员营收报表、员工管理、卡种配置PC 浏览器每日/每月对账前台是使用频率最高的角色所有操作必须在 3 次点击内完成。教练端要轻最好打开就能看到「今天有什么课、谁约了」。会员端最核心的是「我还能来几次、什么时候到期」。管理员端不追求实时但报表要准。2.2 权限模型选型RBAC 够用别上 ABAC常见做法是用 RBAC基于角色的访问控制四张表搞定用户表、角色表、权限表、用户角色关联表。不要一上来就搞 ABAC 或策略引擎健身房场景的权限粒度到「菜单按钮」级别就够了。-- 角色权限核心表结构 CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) UNIQUE NOT NULL, password_hash VARCHAR(128) NOT NULL, real_name VARCHAR(50), phone VARCHAR(20), role_id INT NOT NULL, status TINYINT DEFAULT 1, -- 1启用 0禁用 created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE sys_role ( id INT PRIMARY KEY AUTO_INCREMENT, role_name VARCHAR(30) NOT NULL, -- 前台/教练/会员/管理员 permissions JSON NOT NULL -- 存菜单和按钮权限标识 );permissions字段用 JSON 存权限标识数组比如[member:add,member:renew,checkin:scan]。后端接口用注解或拦截器校验前端根据权限渲染菜单。这样改权限不用改表结构加一个权限标识就行。注意会员和员工不要放同一张用户表。会员有卡种、余额、到期日等业务字段员工有薪资、排班等字段混在一起后期查询会非常痛苦。我一般分sys_user员工和member会员两张主表。3. 数据库设计会员卡、课时、签到三张核心表怎么建3.1 会员卡表把「次卡」和「时间卡」统一建模健身房的卡种五花八门次卡30 次、月卡、季卡、年卡、储值卡。不要为每种卡建一张表用「卡种模板 会员持卡」两层结构。-- 卡种模板定义卡的规则 CREATE TABLE card_type ( id INT PRIMARY KEY AUTO_INCREMENT, type_name VARCHAR(50) NOT NULL, -- 次卡30次/年卡/储值卡 card_category TINYINT NOT NULL, -- 1次卡 2时间卡 3储值卡 total_times INT DEFAULT 0, -- 次卡总次数时间卡为0 valid_days INT DEFAULT 0, -- 有效天数次卡为0表示不限 price DECIMAL(10,2) NOT NULL, status TINYINT DEFAULT 1 ); -- 会员持卡记录 CREATE TABLE member_card ( id BIGINT PRIMARY KEY AUTO_INCREMENT, member_id BIGINT NOT NULL, card_type_id INT NOT NULL, remaining_times INT DEFAULT 0, -- 剩余次数 balance DECIMAL(10,2) DEFAULT 0, -- 储值余额 start_date DATE NOT NULL, expire_date DATE, -- 到期日次卡可为空 status TINYINT DEFAULT 1, -- 1正常 2已用完 3已过期 INDEX idx_member (member_id), INDEX idx_expire (expire_date) );card_category决定业务逻辑分支次卡扣remaining_times时间卡校验expire_date储值卡扣balance。签到接口里用switch分支处理逻辑清晰。3.2 课程与排课表团课和私教分开还是合并团课多人约同一节课和私教一对一的排课逻辑不同。团课有容量上限私教没有。我一般用一张course_schedule表加course_type字段区分CREATE TABLE course_schedule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_name VARCHAR(100) NOT NULL, course_type TINYINT NOT NULL, -- 1团课 2私教 coach_id BIGINT NOT NULL, start_time DATETIME NOT NULL, end_time DATETIME NOT NULL, max_capacity INT DEFAULT 1, -- 团课容量私教为1 booked_count INT DEFAULT 0, -- 已预约人数 status TINYINT DEFAULT 1, -- 1可预约 2已满 3已取消 INDEX idx_coach_time (coach_id, start_time) ); CREATE TABLE course_booking ( id BIGINT PRIMARY KEY AUTO_INCREMENT, schedule_id BIGINT NOT NULL, member_id BIGINT NOT NULL, booking_status TINYINT DEFAULT 1, -- 1已约 2已签到 3未到 4已取消 created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_schedule_member (schedule_id, member_id) );uk_schedule_member唯一索引防止同一会员重复约同一节课。booked_count用乐观锁更新避免并发超约。3.3 签到记录表别只存一条流水签到不只是记一笔还要关联扣次/扣费。设计时把「签到动作」和「扣减动作」分开CREATE TABLE checkin_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, member_id BIGINT NOT NULL, member_card_id BIGINT NOT NULL, checkin_time DATETIME DEFAULT CURRENT_TIMESTAMP, checkin_type TINYINT NOT NULL, -- 1入场 2团课 3私教 deduct_times INT DEFAULT 0, -- 本次扣减次数 deduct_amount DECIMAL(10,2) DEFAULT 0, operator_id BIGINT, -- 操作人前台 remark VARCHAR(200), INDEX idx_member_time (member_id, checkin_time) );这样月底统计「某会员来了多少次、扣了多少次」直接查这张表不用去翻会员卡的变更历史。4. 核心功能实现签到扣次、排课冲突检测、到期提醒4.1 签到扣次接口事务和并发怎么处理签到是最高频操作高峰期可能同一会员在多台设备上同时操作虽然少见但要防。核心逻辑查卡 → 校验状态 → 扣减 → 写记录四步必须在一个事务里。# Python Flask 示例签到扣次 from flask import request, jsonify from models import db, MemberCard, CheckinRecord from sqlalchemy import update app.route(/api/checkin, methods[POST]) def checkin(): member_id request.json[member_id] operator_id request.json[operator_id] # 行锁查询防止并发扣减 card MemberCard.query.filter_by( member_idmember_id, status1 ).with_for_update().first() if not card: return jsonify({code: 400, msg: 无有效会员卡}) # 时间卡校验到期日 if card.card_category 2 and card.expire_date date.today(): return jsonify({code: 400, msg: 会员卡已过期}) # 次卡校验剩余次数 if card.card_category 1 and card.remaining_times 0: return jsonify({code: 400, msg: 次数已用完}) # 扣减 if card.card_category 1: card.remaining_times - 1 elif card.card_category 3: card.balance - 30 # 单次入场扣30元实际从配置读 record CheckinRecord( member_idmember_id, member_card_idcard.id, checkin_type1, deduct_times1 if card.card_category 1 else 0, deduct_amount30 if card.card_category 3 else 0, operator_idoperator_id ) db.session.add(record) db.session.commit() return jsonify({code: 200, msg: 签到成功, remaining: card.remaining_times})with_for_update()是关键它给查询行加排他锁防止两个请求同时读到remaining_times1然后都扣成 0。参数说明checkin_type区分入场、团课、私教扣减规则不同deduct_amount从卡种配置读不要硬编码。4.2 排课冲突检测教练和时间两个维度排课时最容易翻车的是教练时间冲突。同一教练同一时间段不能有两节课检测逻辑用 SQL 的区间重叠判断-- 检测教练在指定时间段是否已有排课 SELECT COUNT(*) FROM course_schedule WHERE coach_id ? AND status ! 3 AND start_time ? -- 新课程结束时间 AND end_time ?; -- 新课程开始时间如果返回大于 0说明有冲突。这个条件start_time new_end AND end_time new_start是标准的区间重叠判断比用BETWEEN更准确能覆盖「新课程完全包含旧课程」的情况。团课还要检测容量booked_count max_capacity时不允许再约。预约接口里用乐观锁UPDATE course_schedule SET booked_count booked_count 1 WHERE id ? AND booked_count max_capacity;影响行数为 0 说明已满返回「课程已约满」。4.3 到期提醒定时任务还是实时计算会员卡到期提醒有两种做法定时任务每天扫一遍快到期会员发通知或者会员每次打开小程序时实时算。我一般两个都做定时任务负责推送短信/微信模板消息实时计算负责页面展示。# 每天上午10点执行扫描7天内到期的会员 from datetime import date, timedelta def scan_expiring_members(): target_date date.today() timedelta(days7) cards MemberCard.query.filter( MemberCard.status 1, MemberCard.expire_date target_date, MemberCard.card_category 2 ).all() for card in cards: member Member.query.get(card.member_id) # 发送提醒具体渠道按实际接入 send_notification(member.phone, f您的会员卡将于{card.expire_date}到期)参数说明提前 7 天是常见值太早会员不着急太晚来不及续。card_category 2只查时间卡次卡没有到期日。5. 避坑与排查上线后最容易翻车的 5 个地方5.1 签到并发导致次数扣成负数现象会员剩余 1 次前台和会员端同时操作扣完变成 -1。原因查询和更新之间没有锁两个请求都读到 1都执行减 1。解决用with_for_update()行锁或者用原子更新UPDATE member_card SET remaining_times remaining_times - 1 WHERE id ? AND remaining_times 0检查影响行数。5.2 团课超约booked_count 和实际预约数不一致现象课程容量 10 人实际约了 12 人。原因booked_count更新和course_booking插入不在同一事务或者并发时没加条件。解决预约接口用事务包裹UPDATE ... WHERE booked_count max_capacity和插入预约记录一起提交。定期用SELECT COUNT(*) FROM course_booking WHERE schedule_id ? AND booking_status 1对账修复。5.3 会员卡到期日算错自然日还是 24 小时现象会员 1 月 1 日办月卡1 月 31 日来被告知已过期。原因expire_date用start_date 30天算成 1 月 31 日但业务上应该包含当天。解决到期日算start_date valid_days - 1或者校验时用expire_date today而不是。我一般存到期日当天的 23:59:59校验时比较时间戳。5.4 教练排课跨天导致冲突检测失效现象教练晚上 11 点排了一节到凌晨 1 点的私教第二天早上 9 点的课检测不到冲突。原因冲突检测只比较了日期没比较具体时间。解决start_time和end_time用DATETIME类型冲突检测用完整时间戳比较不要只比DATE。5.5 营收报表对不上退款和赠送次数没记流水现象月底报表营收比实际收款多因为赠送次数被算成了收入。原因办卡时赠送的 5 次没有单独记录报表按卡种原价统计。解决所有次数和金额变动都写一条member_card_log流水表报表只统计change_type paid的记录赠送走change_type gift。6. 进阶技巧用签到数据做会员流失预警系统跑起来后最有价值的不是签到功能本身而是签到数据。我一般会加一个简单的流失预警连续 14 天没有签到记录的活跃会员标记为「流失风险」推送给会籍顾问跟进。-- 查询流失风险会员过去有签到但最近14天无记录 SELECT m.id, m.real_name, m.phone, MAX(c.checkin_time) AS last_visit FROM member m JOIN checkin_record c ON c.member_id m.id WHERE m.status 1 GROUP BY m.id HAVING last_visit DATE_SUB(NOW(), INTERVAL 14 DAY) AND last_visit DATE_SUB(NOW(), INTERVAL 60 DAY);last_visit 60天是为了排除已经彻底不来的只抓「最近突然不来了」的。这个查询跑出来通常几十条会籍顾问一天跟进 10 个转化率比盲目打电话高得多。验证方法上线后第一周每天人工核对签到记录和会员卡余额确认扣减无误。第二周开始跑流失预警对比跟进前后的续卡率。我自己的习惯是每加一个功能先手动造 10 条测试数据跑一遍边界比如剩余 0 次签到、过期卡签到、重复预约同一节课这些场景不测上线必翻车。这套系统不大但把会员、课程、签到、报表四个模块串起来足够支撑一家中型健身房的日常运营。先跑通签到扣次这个最小闭环再往上加排课和报表别一上来就搞微服务。希望帮到你。本文还有配套的精品资源点击获取