一、系统架构设计与技术选型
一套完整的健身场馆无人自动化系统，在逻辑上分为用户端、管理端和硬件设备端三大部分。基于主流开源技术栈，推荐采用前后端分离架构。
核心技术栈清单：
- 后端服务：Spring Boot 作为主框架，MyBatis Plus 作为ORM层，极大简化单表与多表操作。
- 数据库：MySQL 8.x，利用InnoDB引擎保障事务一致性；Redis用于处理高并发下的Token缓存、设备状态缓存及分布式锁。
- 用户端（C端）：采用UniApp（Vue语法）进行跨平台开发，一套代码可同时编译为H5、小程序和Android/iOS的APP。
- 管理后台：Vue 3 + Element UI Plus，负责场馆管理、订单查看、设备监控、财务报表等功能。
- 硬件对接：通过Netty或MQTT协议与门禁闸机、智能储物柜、灯光电源控制器进行长连接通信。
整体架构可采用微服务或模块化单体架构。对于多数中型场馆（如羽毛球馆、健身房），模块化单体是更务实的选择------按业务边界拆分为用户模块、订单模块、设备模块、会员模块，通过Maven多模块管理，部署简单且易于维护。
二、核心功能模块与代码实现要点
无人系统的难点在于"业务闭环"：用户从线上预订到场、扫码开门、使用设备、自动计费到离场结算，全程无需人工干预。下面拆解几个核心业务流程的技术实现。
1. 智能门禁与订单状态机
门禁控制是无人系统的道关卡。用户在线上完成预订或购买时段后，系统生成一个动态。门禁设备通过内置摄像头或扫码枪识别，并调用后端接口验证订单有效性。
关键逻辑在于订单状态机的设计。建议定义以下状态：
PENDING（待支付）PAID（已支付/待使用）CHECKED_IN（已入场/使用中）COMPLETED（已完成/已离场）CANCELLED（已取消）REFUNDING（退款中）
当用户扫码入场时，接口需要校验订单归属、时间有效性（是否在预约时间段内）以及是否重复使用。下述代码展示了基于Spring Boot的入场校验逻辑：
java
public AjaxResult checkIn(String orderNo, Long userId) {
OrderInfo order = orderMapper.selectByOrderNo(orderNo);
if (order == null) {
return AjaxResult.error("订单不存在");
}
if (!order.getUserId().equals(userId)) {
return AjaxResult.error("无权使用该订单");
}
// 校验订单时间是否在当前时间前后15分钟内
LocalDateTime now = LocalDateTime.now();
if (order.getStartTime().minusMinutes(15).isAfter(now)
|| order.getEndTime().plusMinutes(15).isBefore(now)) {
return AjaxResult.error("当前时间不在可用时段内");
}
// 使用Redis分布式锁防止并发重复入场
String lockKey = "lock:order:" + orderNo;
boolean locked = redisTemplate.opsForValue()
.setIfAbsent(lockKey, "1", Duration.ofSeconds(10));
if (!locked) {
return AjaxResult.error("操作过于频繁，请稍后再试");
}
try {
if (order.getStatus() != OrderStatus.PAID.getCode()) {
return AjaxResult.error("订单状态异常");
}
order.setStatus(OrderStatus.CHECKED_IN.getCode());
orderMapper.updateById(order);
// 异步通知门禁设备打开闸机
deviceService.sendOpenDoorCommand(order.getVenueId());
return AjaxResult.success("入场成功");
} finally {
redisTemplate.delete(lockKey);
}
}对于入场后的自动计费，系统需要通过定时任务或延迟队列来检测用户是否超时未离场。实例如下：当用户入场时，向RabbitMQ发送一条延迟消息（延迟时间=订单结束时间-当前时间）。订单结束时间到达时，消费者检查订单状态，若仍为CHECKED_IN，则自动结算并释放场地，将订单置为COMPLETED，同时向用户推送离场提醒。
数据库表设计建议：
sql
CREATE TABLE `billing_rule` (
`id` bigint NOT NULL AUTO_INCREMENT,
`venue_id` bigint DEFAULT NULL COMMENT '场馆ID',
`rule_name` varchar(50) DEFAULT NULL COMMENT '规则名称（如工作日白天）',
`start_time` time DEFAULT NULL,
`end_time` time DEFAULT NULL,
`min_duration` int DEFAULT '1' COMMENT '短时长（小时）',
`status` tinyint DEFAULT '1',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;在服务层，通过策略模式（Strategy Pattern）根据订单时段动态匹配对应的计费规则。避免使用大量if-else进行判断，提高后期维护效率。
三、部署全流程与硬件联动配置
开发完成后，部署环节是保障系统稳定运行的关键。无人系统不仅涉及软件部署，还涉及硬件网络配置。
1. 软件环境部署（以Docker为例）
推荐使用Docker Compose进行编排，将MySQL、Redis、后端服务、前端静态资源一键化部署。以下为一个简化的docker-compose.yml配置：
yaml
version: '3.8'
services:
mysql:
image: mysql:8.2
container_name: gym-mysql
environment:
MYSQL_ROOT_PASSWORD: your_secure_pwd
MYSQL_DATABASE: gym_system
ports:
- "3306:3306"
volumes:
- ./data/mysql:/var/lib/mysql
command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
redis:
image: redis:7.0
container_name: gym-redis
ports:
- "6379:6379"
backend:
build: ./backend
container_name: gym-backend
depends_on:
- mysql
- redis
ports:
- "8080:8080"
environment:
SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/gym_system?useUnicode=true&characterEncoding=utf8
SPRING_REDIS_HOST: redis
web-pc:
build: ./frontend-admin
container_name: gym-admin
ports:
- "8081:80"
depends_on:
- backend2. 硬件设备接入与局域网隔离
场馆内的智能门禁、照明控制、摄像头等设备，建议通过独立的IoT网关接入，与业务服务之间采用MQTT协议通信。设备上线后，服务端保存设备的sn码与场馆ID的绑定关系。
务必做好设备离线补偿机制：当网络抖动导致门禁无法连接云端时，门禁控制器应支持本地白名单模式的离线验证（在设备端缓存近2小时的订单数据）。恢复连接后，设备将离线日志上传至服务端，由定时任务对账，避免资损。
四、数据安全与稳定性保障
健身场馆无人自动化系统直接关系到用户资金与隐私，在发布前需要重点检查以下几点：
- 接口幂等性：用户端网络不稳定时，支付回调、入场请求可能被重复发送。所有写操作需要考虑幂等键（Idempotent Key），建议使用Redis存储流水号，防止重复消费。
- 数据脱敏：用户、身份证号（用于实名制入场）在数据库存储必须加密（如使用AES或国密SM4）。日志中严禁明文打印。
- 高可用架构 ：定时对账任务确保订单状态与硬件实际状态一致。比如每天凌晨检查昨日订单，若存在
CHECKED_IN状态的僵尸订单，自动触发强制结束流程。
五、常见问题与FAQ
Q1：健身场馆无人自动化系统需要哪些硬件基础？
至少需要智能门禁闸机（支持识别）、监控摄像头（带人形检测）、智能电表或电源控制器（用于远程断电/通电）。如果涉及淋浴或储物，还需配套智能锁柜。
Q2：用户在小程序端预订后，如何实现自动化退款？
退款逻辑通常接入或支付宝的原路退回接口。在无人系统中，推荐使用延迟队列：用户入场后如果在前15分钟内未实际使用设备（如门禁未触发），系统自动触发退款任务。超过时限则可通过管理后台人工介入。
Q3：系统如何应对高峰期的高并发抢购？
针对热门时段的抢购（如周一晚8点的羽毛球场地），数据库层面要对场地索引加锁防止超卖。同时，通过Redis对场地ID加分布式锁，并将可售库存预热到Redis中，配合Lua脚本进行原子扣减。
Q4：这套系统的多端适配如何实现？
用户端使用UniApp开发，一套代码可以同步发布为小程序、支付宝小程序和H5。管理后台则使用Vue + Element UI，完全走Web响应式布局，在PC和平板上均有良好体验。后端仅需提供标准RESTful API即可支持多端调用。
Q5：零基础团队开发此类系统需要多久？
若基于开源稳定的脚手架（如Spring Boot + MyBatis Plus + Uniapp），且不涉及复杂定制IoT硬件设备，3-4人小团队通常可在2-3个月内完成从设计到上线的原型验证。若需对接复杂门禁、人脸识别等第三方能力，周期会相应延长至5-6个月。开发前务必整理清楚场地管理、预约规则、计费模型等核心业务文档。