记账与可靠投递。不讨论清算、手续费和商户进件。

鸿蒙人脸识别消费机在弱网食堂的核心，不是「还能不能认出人」，而是认出人之后这一笔钱有没有且只记一次。通行闸机的离线缓存是「这人能不能过、事件稍后补」；消费离线是「余额扣没扣、流水号是什么」。二者都叫离线人脸识别，队列语义不同。

---

一、通行补传可以丢顺序，消费补传很难丢顺序

通行日志晚到、乱序，后台多半能按时间戳排序。消费流水乱序或重试产生两笔，会对账失败。因此消费机需要：本地流水号、幂等键、成功落盘后再提示外侧「扣款成功」。提示先于落盘，是窗口纠纷的常见根因。

鸿蒙人脸识别算法只负责「是谁」；「扣多少」是账户服务。把识别成功直接当记账成功，等于把模型抖动变成错账。

---

二、建议拆开的两套队列

人证比对离线补传对账优先级低于消费，高于一般通行刷脸日志（视审计要求）。三套若共用一个 MQTT 主题和同一 backoff，食堂高峰会把人证和通行挤成超时。

---

三、本机余额还是平台余额

本机余额：断网可扣，对账在联网后。要防时钟回拨和余额文件损坏。
平台余额：识别在端、扣款在线。网络抖动等于窗口停。

很多项目写成「在线离线都支持」却不写余额权威。鸿蒙人脸识别消费机预研应画权威点。云识客等整机实践若强调本机比对，指的是身份在端；余额权威仍要单独立项。麒麟 / 统信管理端可以做对账，不要假设 OpenHarmony 终端自带会计科目。

---

四、和人证开户的交叉

有的食堂用身份证人证比对做首次开户，再转人脸消费。这是两个事务拼接：核验成功 ≠ 账户已充值。状态应是 verified / opened / funded 分步。混成一个「刷证就能吃饭」，会出现未充值扣负或未核验开吃。

---

五、小结

离线人脸识别在消费机上首先是记账纪律，在闸机上首先是放行缓存，在人证上首先是会话补传。欢迎讨论你们流水号是终端生成还是平台生成。