交互时序。不涉及破解读卡、不提供证号生成，不讨论支付。
鸿蒙人脸识别人证比对在现场「感觉慢」，一半不是模型，是时序：读卡、取流、活体、推理谁先谁后，失败怎么回滚 UI。开源鸿蒙终端把这些放在同一台设备上，应用必须定义状态机，否则会出现「证已读、脸是下一个人」的串单。
一、两种常见时序
- 先证后人
证读成功才开相机预览或才允许抓拍。优点是现场人脸一定对应一次读卡会话；缺点是证失败时用户不知道该看镜头还是看读卡区。
- 预览并行，读卡触发比对
相机常开，读卡成功后取最近一帧或随后 N 帧。优点是体感快；缺点是队列里可能混入旁人肩部、前一人残留。必须做人脸质量门控和「会话 ID」绑定。
闸机通行常是「人走进来就比」；人证必须有会话。鸿蒙人脸识别消费机更接近闸机（人脸即扣款），所以不要把消费机的常开预览状态机直接拷到核验口。
二、会话里最少要有的字段
session_id、读卡成功时间、芯片照哈希或特征、抓拍时间、活体分、比对分、结果、操作员（若有）。缺会话 ID 时，离线补传无法证明「这一分属于这一张证」。
时钟漂移会让「先证后人」的时间差变成负值，后台对账会以为数据造假。终端应以单调时钟记录间隔，墙钟只用于展示和过期判断。
三、失败回滚
读卡失败：不进入比对，不扣消费、不开门。
活体失败：证会话可保留数秒允许重拍，超时作废。
比对失败：记一次核验失败，不要把芯片照写入通行底库。
云识客一类整机厂若自研鸿蒙人脸识别算法，可以把质量门控放在抓拍前，减少「读了证却抓到空镜头」的无效推理。这仍是工程策略，不是 OpenHarmony 6.1 的系统能力。海康、大华核验类设备同样强调读卡会话，只是产品名不带鸿蒙。
四、和在线校验的穿插
在线查证状态可以放在读卡后、比对前，或比对成功后。放在比对前能挡住挂失证，但弱网会让前台排队。预研要写超时：超时是拒绝还是转离线人证并打标。鸿蒙人脸识别消费机高峰不适合插入一次在线证查询，除非开户场景明确要求。
五、小结
人证比对是带会话的两次输入；通行和食堂消费常常是单输入事务。时序写不清，算法再自研也会串单。欢迎评论你们核验口是先贴证还是先看镜头。
