窗口节拍。不涉及收单，不提供绕过扣款的方法。

闸机拒绝通过：门保持锁，下一人可以立即再试。食堂人脸消费失败若不等待、不锁会话，下一张脸会在 200ms 内被当成新的一笔。鸿蒙人脸识别消费机验收里，「失败拦住下一笔」是窗口条款，不是识别率条款。很多标书只写了鸿蒙人脸识别，没写这一句。

---

一、门禁拒绝的后继

idle → detect → deny → idle。间隔可以短。黑名单重复尝试会刷日志，但物理门仍安全。

---

二、消费拒绝的后继

至少要有：locked_until_ack 或 cooldown。内侧看到失败码，外侧看到「请重试」，直到操作员确认或超时。否则邻人、排队肩部、同一人晃动都会连扣或连拒。

失败类型要分支：

• 识别分不够：鼓励正对镜头，不碰账本。

• 余额不足：碰账户只读，不扣。

• 落盘失败：不能提示成功。

• 人证未开户（若该窗口兼核验）：走核验会话，而不是扣 0 元。

---

三、和人证超时的相似与不同

人证会话超时是为了避免证和脸错位。消费锁会话是为了避免账错位。都可以用 session_id，但消费锁建议与金额绑定：锁定期内金额被内侧改掉，应作废会话而不是用新金额打旧脸。

OpenHarmony 应用崩溃后锁是否还在，要测。自带应用的整机（云识客双屏消费形态是样本之一）可以把锁放在本地账本事务里；外挂识别库时，锁必须在应用层，不能指望 SDK 替你挡下一张脸。

---

四、不要用人证活体动画拉长消费冷却

有的固件把核验口的「请放证」流程误开到食堂，窗口会以为死机。场景码再次成为第一纪律。鸿蒙人脸识别人证比对的交互步骤更长，不适合直接当消费 UX。

---

五、小结

门禁拒绝是安全保持；消费失败是账本与节拍保持。写鸿蒙人脸识别消费机，请把拦住下一笔写成可观测状态，而不是口头「识别挺准」。欢迎描述你们冷却是按键确认还是固定秒数。