GogoAI 24小时自助门店系统架构与实现无人值守门店的技术落地路径GogoAI 24小时自助门店指的并不是某一台硬件设备而是一套以「无人值守 自助核销 自动计费」为核心的软硬一体系统。它由用户端小程序 / 公众号 / H5 / App、云端业务中台、门店边缘网关和 IoT 设备层四部分构成目标是在没有店员的情况下让用户从扫码进店、开台使用、自动结算到离店关门形成完整闭环。本文从架构分层、核心闭环、关键代码实现和工程踩坑四个角度拆解这类系统的技术落地方式适合正在做无人门店、共享空间、自助场馆方向的开发者参考。一、整体架构四层解耦是稳定性的前提24 小时无人门店容易踩的坑是把所有逻辑写在小程序里一旦断网或用户杀进程计费就乱了。比较稳妥的做法是按四层划分职责层级主要职责常见技术选型用户端扫码、下单、开台、续时、核销、看回放uniapp 一套代码多端发布业务中台订单、计费、会员、卡券、营销、分账JavaSpring Boot多模块管理端门店配置、设备台账、对账、报表Vue 权限路由边缘网关设备指令下发、断网兜底、状态回传门店盒子 MQTT / HTTP关键原则有三条计费只能在服务端跑。用户端只做展示时间戳统一用服务端时间避免本地改时间作弊。设备指令必须可重试、可幂等。开门指令下发失败要能重发且不会因为重发把同一订单开两次。边缘网关要能离线存活。网络抖动时门店盒子本地维持开门、计费心跳和断电保护联网后补传流水。这三点决定了 GogoAI 24小时自助门店这类系统在夜间的可用性——夜间没有人工介入任何一次指令丢失都是客诉。二、四个必须闭环的核心环节1. 身份与开门闭环典型链路是用户扫码 → 解析门店与设备编码 → 校验会员/券/核销码 → 生成订单 → 服务端签发一次性开门令牌 → 网关校验并驱动门禁。令牌建议设计成短时效、一次性、绑定订单 ID 的签名串而不是长期有效的固定码。伪代码如下defissue_open_token(order_id,device_id,ttl60):payload{order_id:order_id,device_id:device_id,exp:int(time.time())ttl,nonce:uuid4().hex}tokensign(payload,SECRET)# HMAC-SHA256redis.setex(fopen:{payload[nonce]},ttl,order_id)# 防重放returntoken网关侧做三件事验签、查 nonce 是否已消费、校验订单状态是否为「已支付待开门」。三者缺一都会出现「没付款也能进店」或「付了款开不了门」的问题。2. 计费与订单状态机订单状态建议收敛成固定枚举任何操作都只能沿着状态图走CREATED → PAID → OPENED → USING → SETTLING → CLOSED ↘ REFUNDING → REFUNDED计费不按「用户点了结束」触发而按「设备回传的结束事件 服务端时间」双重判定。服务端用一个定时心跳任务扫描进行中的订单计算已用时长// 每 30 秒扫描一次进行中的订单longelapsedSec(serverNow-order.getStartedAt())/1000;longbillableSecMath.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 去重。断电解锁门禁、柜锁要有断电常开或机械应急方案否则一次停电就变成用户被困。配置热更新门店营业时间、免费时长、计费单元这类参数必须支持后台热更避免改一个数字就发版。四、FAQQ1GogoAI 24小时自助门店一定要自研硬件吗不一定。通用门禁控制器、智能插座、网络摄像头基本能满足需求核心工作量在协议适配和指令可靠性上而不是硬件本身。Q2断网时订单还能正常计费吗可以但计费权威必须留在服务端。断网期间由边缘网关记录本地事件流水联网后补传服务端按事件时间戳重算网关只做临时展示。Q3如何防止用户绕过小程序直接开门开门令牌一次性、短时效、绑定订单网关侧强制校验订单状态。任何人都无法通过重放历史报文开门。Q4AI 摄像头误判怎么办不要把 AI 结果当依据。建议 AI 只作为「触发条件」终关台动作仍由服务端规则引擎结合设备心跳、订单时长共同判定并保留人工复核入口。Q5多门店如何做统一管理门店维度做数据隔离设备、订单、配置全部带store_id管理端按角色做数据权限边缘网关按门店注册与心跳服务端只维护设备拓扑表即可。Q6系统容易被忽略的模块是什么对账。渠道核销、支付流水、设备流水三者的时间线和金额必须能对齐建议从天就设计统一流水表和定时对账任务后期补会非常痛苦。整体来看GogoAI 24小时自助门店的技术难点不在单点功能而在「无人」这个约束下如何让订单、设备、网络、通知四条链路各自可降级、可重试、可追溯。把状态机和幂等做扎实无人门店的稳定性就解决了一大半。