在健身行业从“重服务”向“重体验”转型的当下，24小时自助健身房已成为一二线城市的主流业态。广州作为华南商业核心，其租金成本与人力成本倒逼经营者必须通过技术手段降低运营依赖。本文基于SpringBoot + MyBatis-Plus + MySQL + UniApp + Vue + ElementUI这套组合技术栈，结合物联网(IoT)硬件，给出可落地的**广州24小时自助健身房软硬件解决方案**，覆盖门禁联动、会员小程序、设备控制、异常报警与数据看板，并分享实际部署中的关键代码与避坑经验。

#### 1. 系统总体架构与技术选型

一个完整的24小时自助健身房涉及三端：**用户端（C端）**、**管理后台（B端）**和**硬件控制层（IoT）**。软件层面建议复用成熟开源框架，不必从零搭建。

- **后台服务端**：使用SpringBoot + MyBatis-Plus + MySQL。负责会员管理、订单计费、设备状态转发、消息推送。
- **用户端小程序**：采用UniApp（Vue语法）开发，可一套代码同时编译为小程序、支付宝小程序和H5，便于在广州本地快速传播。
- **管理后台**：采用Vue3 + ElementUI，需实现实时监控页面、财务流水、远程开门、卡密管理等模块。
- **硬件接入层**：人脸识别门禁一体机（支持扫码，选用支持HTTP协议/Modbus协议）、智能电控锁（控制照明与闸机）、AI摄像头（用于人流统计与安全报警）。

以下为简化部署拓扑，软件部分仅关注服务端与硬件的交互：

```text
[用户小程序] <--> [Nginx负载均衡] <--> [SpringBoot API集群] <--> [MySQL主从]
                                    |
                                    +--> [Redis缓存：会员状态、开锁Token]
                                    |
[IoT网关(门禁/电控/摄像头)] <--> [硬件适配层(MQTT/HTTP)] <--> [报警通知服务]
```

架构设计上必须考虑断网情况。硬件端需内置“离线白名单”，当公网中断时，本地MCU仍可根据已同步的会员过期时间决定是否开门。网络恢复后，离线事件记录自动上传补交。

#### 2. 门禁与硬件联动模块：从扫码到开门的10秒体验

24小时无人值守，关键的是门禁与会员状态的实时联动。传统刷卡器已不适用，推荐使用**动态开门**。流程如下：

1. 用户在小程序点击“开门”，后端生成一次性、有效期60秒的随机Token。
2. 门禁机通过HTTP请求（或MQTT长连接）向后端API发起校验。
3. 后端返回加密结果（包含会员状态、是否逾期、当前时间段是否被限制入场）。
4. 门禁机本地校验后触发继电器开锁，同时记录入场时间。

核心校验逻辑示例（服务端Java伪代码）：

```java
@RequestMapping("/api/door/open")
public Result doorOpen(@RequestBody DoorOpenRequest request) {
    // 1. 校验签名（防止请求被篡改）
    if (!SignatureUtil.verify(request.getSign(), secretKey)) {
        return Result.error(401, "签名验证失败");
    }
    // 2. 调用会员服务查询当前状态
    Member member = memberService.getById(request.getMemberId());
    // 3. 检查是否为有效会员（非停卡、非过期、且卡券未用完）
    if (!member.isActive()) {
        return Result.error(403, "会员状态异常，请联系管理员");
    }
    // 4. 生成一次性开门Token并存入Redis（设置60秒过期）
    String token = UUID.randomUUID().toString();
    redisTemplate.opsForValue().set("door:token:" + token,
            request.getDoorId(), 60, TimeUnit.SECONDS);
    // 5. 将Token同步给硬件网关（此处假设MQTT异步下发）
    mqttGateway.sendToDoor("door/" + request.getDoorId(), token);
    return Result.success("success", token);
}
```

**实战经验**：广州地区夏季多雷雨，设备用电环境不稳定。门禁电控锁务必使用12V蓄电池作为备用电源，并在硬件适配层增加“断电检测上报”接口，让管理后台收到停电推送时，可远程通知本地兼职保洁协助手动开门，避免投诉。

#### 3. 会员小程序与设备控制：不只是预约

- **健身设备预约与解锁**：对于跑步机、椭圆机等需要通电的设备，可加装智能插座（支持Wi-Fi或蓝牙Mesh）。用户通过小程序扫码后，后端调用小米/涂鸦等开放平台API或直接下发MQTT指令通电，设备断电延迟30秒，防止用户在运动中突然断电受伤。
- **虚拟教练课程预约**：参考台球厅助教预约逻辑，健身房可引入“私教预约上门”或“自助跟练视频课”。课程表模块需支持教练入驻、时段时间表、取消预约等状态流转。技术逻辑与网约车派单类似，但更强调时间窗冲突校验。
- **社交裂变与老带新**：借鉴家政自营3.0中的团长分销思路，在后台为老会员生成专属邀请。新用户注册成功，双方获得健身时长奖励。这里无需涉及真实金钱交易，仅做积分抵扣。

关键数据表设计（简化）：

```sql
CREATE TABLE `device_usage_log` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `device_id` varchar(32) DEFAULT NULL, -- 设备编号（如RJ01）
  `member_id` bigint(20) DEFAULT NULL,  -- 使用人
  `start_time` datetime DEFAULT NULL,   -- 扫码上电时间
  `end_time` datetime DEFAULT NULL,     -- 停机时间
  `source` varchar(16) DEFAULT 'mini',  -- 渠道：小程序/后台
  PRIMARY KEY (`id`),
  KEY `idx_member_time` (`member_id`,`start_time`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4;
```

注意：对于“按时长计费”或“按次计费”的业务，**不要在小程序端做费控**（客户端不可信），必须以后台服务端收到的上电/下电记录为准。如果设备支持实时功率检测，后台应每30秒采集一次用电数据，防止用户通过拔掉插头逃避计费（需硬件支持防拆螺丝）。

#### 4. 管理后台与异常运维：远程化运营

广州门店数量多且分散，管理后台必须支持多门店权限隔离。每个店长只能看到自己门店的实时客流、设备状态和今日预警记录。推荐开发以下三个核心页面：

**页面一：实时监控大屏**。展示今日入场人数、当前在场人数、设备在线率、预警事件滚动条。在场人数可通过AI摄像头头肩检测算法实现，误差控制在5%以内。该数据联动风控引擎——若凌晨1点后在场人数为0且门磁状态为“已关闭”，系统自动触发夜间巡检模式。

**页面二：设备故障工单**。当硬件心跳信号连续3分钟丢失，后台自动生成待处理工单，并推送飞书/钉钉机器人消息给对应片区运维员。注意，如果没有第三方运维团队，可设置“会员报障”入口，用户端一键提交照片，后台自动关联设备的异常日志，缩短排查时间。

关于异常报警设置，需要设置双阈值。例如：

- 阈值A：同一用户单日入场超过5次，触发“疑似借用”警告。
- 阈值B：环境温度高于40℃，立即切断非必要设备电源并发送高温预警（防止设备自燃风险）。

#### 5. 安全策略与数据隐私：无人却不可无防

无人健身房涉及三个安全维度：**财物安全**、**人身安全**和**数据安全**。

- **财物安全**：建议在门禁硬件上增加“防尾随”红外对射装置，并在人脸识别摄像头中加入活体检测，防止照片开门。
- **人身安全**：为每间门店设置一键呼叫按钮（带语音对讲），服务端需接入阿里云或腾讯云隐私号码服务。这类似于台球厅系统中的“虚拟”功能，用户按下按钮后，系统通过API创建一个临时虚拟号接通店长手机，保护双方真实号码不泄露。
- **数据安全**：门禁和摄像头产生的视频流不应直接存储公网。采用本地NVR存储+定时上传关键帧的方式。后台查询用户开门记录时，需权限分离，普通运营只能看到脱敏后的数据（如`139****1234`）。

隐私保护方面，建议在服务端对视频文件名称进行MD5不可逆加密。当出现纠纷需要提取证据时，由管理员在审计日志中申请解密，该过程应留痕。

#### FAQ（常见问题与实战解答）

**Q1：广州本地环境复杂，如果门店没有光纤宽带，只有移动网络，门禁能否正常工作？**
A：可以。门禁一体机建议选择支持4G Cat.1通信的型号，但需要确保物联网卡配置了DNS解析。支付类环境建议使用公网IP或云服务器中转，不要使用普通宽带动态DNS，否则会导致回调不稳定。若有条件，可在门禁内加装离线SD卡存储放行名单数据。

**Q2：如何应对用户过了营业时间仍在健身房内不走的情况？**
A：技术解决思路是“顺风耳”与“灯光驱逐”。后台设置营业结束时间，到达后系统自动对场内播放语音提示，并将灯光调暗至30%。15分钟后若门磁仍未检测到开闭门记录，后台启动二次报警，通知周边安保或店长。注意，法律层面不允许强行断电驱离，必须留出30分钟缓冲期。

**Q3：现有传统健身房想升级为24小时模式，但不想更换全部跑步机，怎么办？**
A：硬件上加装“智能电控箱”——在健身房总电箱接入一路受控继电器，该继电器的控制信号接入IoT网关。原有跑步机只需插在这个受控插座上即可。通过后端的API控制通断电，实现传统设备的智能化改造，改造时间通常只需半天。

**Q4：会员数据量变大后，MySQL查询卡顿，如何处理？**
A：在开发初期就要按“门店ID”作为分表键。例如将`device_usage_log`按月拆表，查询时通过路由规则拼接表名。同时建立Redis缓存热点数据（当前在场人数、门禁Token），这类数据不要直接查数据库，避免高并发时被打爆。