多门店管理篇：健身房连锁运营的技术中台

当单一健身门店的盈利模型跑通后，“复制成功”成为连锁扩张的必然需求——而这也恰恰是技术架构分崩离析的高危节点。

关键升级：门店管理模块

连锁架构下，核心是解决“单店隔离+集团统管”的矛盾。系统需引入“门店分组”概念（类似UniApp在多家共享场景中的应用逻辑）：

• 门店独立账户体系：每店拥有独立管理员账号，可通过管理后台分配各自的库存（会员卡库存、课程时段额度）、设备分组权限（某店管理员仅能操作本店的灯控与门禁）。
• 跨店数据漫游：用户端基于UniApp的用户ID绑定一个“常驻门店”，但允许会员通过App端切换门店查看可用时段与设备状态——背后的技术方案是路由拦截中间件（例如Vue Router的导航守卫），自动在API请求头中注入shop_id参数。
• 集团聚合看板：管理后台（Vue+Element UI）提供一个“仪表盘”，透视所有门店的实时入店人数、设备使用率、会员增长率，用Redis做实时缓存，避免频繁查询MySQL产生性能瓶颈。

技术细节：门店区分与数据隔离

实践中会出现一个棘手问题：若会员购买了“A店年度卡”，是否能去B店锻炼？这需要后台设置“通卡”与“单店卡”策略。

为实现公平计费，建议在数据库membership表增加shop_id字段（可空）。当shop_id为null时，识别为全门店通用卡；有具体值时，仅限该店使用，并配合校验中间件：每次刷入闸时，shop_id校验若失败，设备端立即返回“非授权门店”的错误码。

数据隔离方面，每个门店的运营数据（流水、课时记录、设备异常日志）均添加shop_id作为分区键，保证独立的数据库分表或集群水平扩展的灵活性——类似无人茶室系统中的Php+MySQL分库分表优化策略。

智能设备与嵌入：从“看门”到“会算账”

自助健身房真正的技术壁垒在于“软硬一体”。用户看不到的代码库背后，是设备指令控制、视频流分析等门道。

门禁与灯控的闭环逻辑

• 门禁策略：放弃传统“扫码即开”的简单模式，采用“二次核验”机制。次核验是用户扫描（或输入验证码）→后台（Spring Boot）通过JwtToken解析用户权限→下发开门指令（MQTT协议发送至网关）。进门后，灯控设备通过红外传感器配合继电器工作——若用户在30秒内未过闸，门禁自动关闭并广播“超时未入场”事件给管理员。
• 设备心跳检测：为避免设备掉线影响运营，引入“心跳包”机制。健身器械（如跑步机、力量训练设备）每10秒向云端发送{device_id, status, power_consumption}JSON数据。若连续3次无响应，系统自动标记该设备为“离线”并告警给后台。

计费规则可视化配置

• 数据库建立billing_rules表，字段包括：rule_name（如“周末折扣”）、apply_area（所有/指定门店）、condition_json（例如{"begin_hour": 17, "end_hour": 23, "day_of_week": [6,7]}）。
• 用户扫码使用设备时，系统根据当前时间遍历所有规则（使用MySQL JSON函数+Lua脚本做原子性匹配）。匹配成功后，触发计费调整：实际金额 = 标准单价 ×discount_rate。
• 自动化结算的难点在于“中途中断”：如果用户在优惠时段结束后仍在用设备，需要启动“分段计费逻辑”。我们在Spring Boot项目里引入TimerTask，每分钟检查一次设备设备占用情况，对状态变更事件做批量处理。

会员增长与裂变：用技术替代地推

传统健身房依赖销售军团，自助模式则仰仗系统自带的“病毒系数”。实践中技术实现应聚焦三个关键点：

1. 社群论坛与积分系统

参考无人台球室的社交论坛设计与共享棋牌室的用户端交互逻辑：

• 用户端基于UniApp实现“运动打卡”、“课程评价”、“健身搭子”等发帖功能。后台用ElasticSearch（ES）做帖子内容的全站检索，支持标签筛选（#减脂 #增肌 #新人）。
• 特别注意：积分系统要防刷。比如同一设备ID（通过UniApp的plus.device.uuid获取）频繁发帖时，触发风控，要求滑块验证或暂停发放积分。

2. 活动管理与赛事模块

• 支持创建线上挑战赛（比如“30天打卡计划”）和线下赛事（如“硬拉大赛”），后台（Vue+Element UI）配置event表，包括报名费、排名规则、奖品池。
• 技术难点在于“赛事排行榜实时更新”：前端通过WebSocket订阅事件，后端采用Redis的ZSet（有序集合）存储参赛者成绩：ZINCRBY event:123:leaderboard timestamp member来动态排名。
• 赛事结束后，自动生成“成绩证书”（PDF文件），利用Java的iText库从模板渲染，并推送至用户手机。

3. AI摄像头与动作分析（可选）

如果在共享羽毛球、无人健身房场景中引入AI，技术上可考虑：

• 训练阶段：准备健身动作视频数据集，用OpenPose提取人体骨骼关键点，输入至YOLOv8模型进行动作识别。
• 推理阶段：店内摄像头接入NVIDIA Jetson边缘盒子，运行轻量化模型，实时分析用户动作正确性，异常动作（如卧推杠铃下滑、深蹲膝盖过伸）通过回调接口推送预警。
• 这种方式不仅能降低损坏概率，还成为营销亮点——不过需要提醒开发团队，这涉及硬件投入与算法团队协作，小型项目建议先关闭此模块，仅保留基础视频存储与回放功能。

FAQ：24小时自助健身房系统开发常见问题

Q1：开发这套系统需要几人团队？
A：建议小团队配置：1名全栈开发（熟悉Spring Boot/UniApp/Vue）、1名嵌入式工程师（负责门禁、灯控，懂MQTT协议）、1名测试兼运维（负责Docker环境搭建与设备调试）。若团队只有2人，可优先用开源项目或第三方API解决AI部分。

Q2：管理后台如何支持“多门店批量发放优惠券”？
A：数据库层面，在coupon表设计shop_scope字段（存储JSON数组如["shop_1","shop_2"]）。运营人员在选择门店时，后台勾选“全部门店”即发送null值表示各店通用，核心是增加一个“批量触发”按钮，利用消息队列（如RabbitMQ）排队发放，避免高并发内存溢出。

Q3：系统需要对接哪些第三方服务？费用如何？
A：通常包括：短信服务（用于验证码）、云点播/直播（视频回放存放）、地图API（显示附近门店）、支付/支付宝（在线支付）。具体成本根据访问量浮动，但除支付机构抽成外，其他服务通常有免费额度或按量计费。

Q4：系统怎么处理一次网络波动导致的门禁误判？
A：我们引入“超时补偿”机制：当设备因网络断开未收到开门指令时，用户会看到滚动提示“网络异常，请稍候”，同时设备网关缓存当前请求，待恢复连接后由Spring Boot的定时任务重试。若多次失败，系统自动推送人工客服工单。

Q5：用户的会员卡能跨店使用吗？
A：取决于系统配置。系统预留了membership_policy表，其中is_global_cross_shop字段控制此行为。设置为false时，校验中间件会拦截非本店开卡用户。通常建议连锁前两个月开放“试用跨店”，待稳定后再限制范围。