GogoAI 24小时自助门店系统架构与实现：无人值守门店的技术落地路径
GogoAI 24小时自助门店，指的并不是某一台硬件设备，而是一套以「无人值守 + 自助核销 + 自动计费」为核心的软硬一体系统。它由用户端（小程序 / 公众号 / H5 / App）、云端业务中台、门店边缘网关和 IoT 设备层四部分构成，目标是在没有店员的情况下，让用户从扫码进店、开台使用、自动结算到离店关门形成完整闭环。本文从架构分层、核心闭环、关键代码实现和工程踩坑四个角度，拆解这类系统的技术落地方式，适合正在做无人门店、共享空间、自助场馆方向的开发者参考。
一、整体架构：四层解耦是稳定性的前提
24 小时无人门店容易踩的坑，是把所有逻辑写在小程序里，一旦断网或用户杀进程，计费就乱了。比较稳妥的做法是按四层划分职责：
| 层级 | 主要职责 | 常见技术选型 |
|---|---|---|
| 用户端 | 扫码、下单、开台、续时、核销、看回放 | uniapp 一套代码多端发布 |
| 业务中台 | 订单、计费、会员、卡券、营销、分账 | Java（Spring Boot）多模块 |
| 管理端 | 门店配置、设备台账、对账、报表 | Vue + 权限路由 |
| 边缘网关 | 设备指令下发、断网兜底、状态回传 | 门店盒子 + MQTT / HTTP |
关键原则有三条：
- 计费只能在服务端跑。用户端只做展示，时间戳统一用服务端时间，避免本地改时间作弊。
- 设备指令必须可重试、可幂等。开门指令下发失败要能重发，且不会因为重发把同一订单开两次。
- 边缘网关要能离线存活。网络抖动时，门店盒子本地维持开门、计费心跳和断电保护，联网后补传流水。
这三点决定了 GogoAI 24小时自助门店这类系统在夜间的可用性——夜间没有人工介入，任何一次指令丢失都是客诉。
二、四个必须闭环的核心环节
1. 身份与开门闭环
典型链路是：用户扫码 → 解析门店与设备编码 → 校验会员/券/核销码 → 生成订单 → 服务端签发一次性开门令牌 → 网关校验并驱动门禁。
令牌建议设计成短时效、一次性、绑定订单 ID 的签名串，而不是长期有效的固定码。伪代码如下：
defissue_open_token(order_id,device_id,ttl=60):payload={"order_id":order_id,"device_id":device_id,"exp":int(time.time())+ttl,"nonce":uuid4().hex}token=sign(payload,SECRET)# HMAC-SHA256redis.setex(f"open:{payload['nonce']}",ttl,order_id)# 防重放returntoken网关侧做三件事：验签、查 nonce 是否已消费、校验订单状态是否为「已支付待开门」。三者缺一，都会出现「没付款也能进店」或「付了款开不了门」的问题。
2. 计费与订单状态机
订单状态建议收敛成固定枚举，任何操作都只能沿着状态图走：
CREATED → PAID → OPENED → USING → SETTLING → CLOSED ↘ REFUNDING → REFUNDED计费不按「用户点了结束」触发，而按「设备回传的结束事件 + 服务端时间」双重判定。服务端用一个定时心跳任务扫描进行中的订单，计算已用时长：
// 每 30 秒扫描一次进行中的订单longelapsedSec=(serverNow-order.getStartedAt())/1000;longbillableSec=Math.max(0,elapsedSec-order.getFreeSeconds());intunitCount=(int)Math.ceil(billableSec/(double)order.getUnitSeconds());order.setUnits(unitCount);orderMapper.updateUnits(order.getId(),unitCount);这里有两个细节值得注意：一是向上取整要统一，用户端展示和服务端结算必须用同一套算法，否则对账必炸；二是封顶逻辑要显式写入配置，比如长可用时长、超时自动关台，避免用户忘记结束导致订单挂死。
3. AI 视觉与设备状态校验
无人门店的设备状态不能只依赖用户操作。摄像头在这里承担两个角色：
- 占用检测：通过画面变化判断空间是否仍有人/是否已清场，用于超时清场和自动关台；
- 事件留证：把开台、结束、异常告警的时间点与视频片段关联，方便后续追溯。
工程上建议把算法侧输出统一成事件流（event stream），而不是让业务代码直接读视频：
{"device_id":"cam-01","event":"area_empty","confidence":0.93,"ts":1730000000,"ref_order":"O2024xxxx"}业务侧只订阅事件，不关心模型细节，后续换算法或加一路摄像头都不影响订单逻辑。
4. 通知与安全策略
夜间无人值守，通知就是的「服务员」。常见通道组合是：小程序订阅消息 + 公众号模板消息 + App 推送，关键节点（即将超时、已自动关台、退款到账）用提醒兜底。同时，涉及用户与技师、用户与用户之间的通话，建议走隐私号中转，避免真实号码外泄。
三、实战踩坑清单
- 时钟漂移：门店盒子与云端时间不同步会导致计费偏差。务必启用 NTP，并在订单里同时记录设备时间和服务器时间，结算以服务器为准。
- 重复核销：抖音、美团等渠道码必须做幂等表，
(channel, code)索引 + 事务内状态校验，防止同一张券核两次。 - 断网续传：网关本地用 SQLite 或轻量队列缓存指令流水，联网后按时间序补传，服务端按 nonce 去重。
- 断电解锁：门禁、柜锁要有断电常开或机械应急方案，否则一次停电就变成用户被困。
- 配置热更新：门店营业时间、免费时长、计费单元这类参数必须支持后台热更，避免改一个数字就发版。
四、FAQ
Q1：GogoAI 24小时自助门店一定要自研硬件吗？
不一定。通用门禁控制器、智能插座、网络摄像头基本能满足需求，核心工作量在协议适配和指令可靠性上，而不是硬件本身。
Q2：断网时订单还能正常计费吗？
可以，但计费权威必须留在服务端。断网期间由边缘网关记录本地事件流水，联网后补传，服务端按事件时间戳重算，网关只做临时展示。
Q3：如何防止用户绕过小程序直接开门？
开门令牌一次性、短时效、绑定订单，网关侧强制校验订单状态。任何人都无法通过重放历史报文开门。
Q4：AI 摄像头误判怎么办？
不要把 AI 结果当依据。建议 AI 只作为「触发条件」，终关台动作仍由服务端规则引擎结合设备心跳、订单时长共同判定，并保留人工复核入口。
Q5：多门店如何做统一管理？
门店维度做数据隔离，设备、订单、配置全部带store_id，管理端按角色做数据权限，边缘网关按门店注册与心跳，服务端只维护设备拓扑表即可。
Q6：系统容易被忽略的模块是什么？
对账。渠道核销、支付流水、设备流水三者的时间线和金额必须能对齐，建议从天就设计统一流水表和定时对账任务，后期补会非常痛苦。
整体来看，GogoAI 24小时自助门店的技术难点不在单点功能，而在「无人」这个约束下，如何让订单、设备、网络、通知四条链路各自可降级、可重试、可追溯。把状态机和幂等做扎实，无人门店的稳定性就解决了一大半。
