状态机与数据驻留。不提供可利用的绕过步骤，不引导站外服务。

「支持在线离线人脸识别 + 身份证比对」写进方案后，评委常追问一句：离线时到底比的是什么。若答案只是「本机还能刷」，无法区分三种库：正式通行名单、人证临时照、以及待补传的核验日志。鸿蒙人脸识别终端把比对放在开源鸿蒙上，并不自动规定这三种库的生命周期。

---

一、在线人证：权威在哪

在线模式通常多一次外部确认：证号、有效期、是否在黑名单、是否允许登记。人脸比对仍可在端侧完成，服务端只收结果和证号摘要。把整张芯片照和现场原图都甩到公有云，会和「数据不出域」材料冲突，也不是 OpenHarmony 终端的必然路径。

在线失败要定义降级：拒绝、改人工，还是允许离线人证但打「待复核」标记。降级策略属于业务，不是鸿蒙人脸识别算法的默认值。

---

二、离线人证：本机必须具备的最小集合

离线人脸识别在闸机场景里，底库是已授权名单。人证比对离线时，允许名单为空。两套离线若共用一个「本地库」键，核验通过的陌生人可能被误写成可开门。

---

三、和消费机离线不是同一队列

鸿蒙人脸识别消费机断网时，要保证扣款原子性和流水补传，失败要拦住下一笔。人证离线要保证「这次核验有没有完成、结果是什么」。把消费补传队列和人证补传队列合成一个 MQTT 重试器，现场会出现：食堂高峰把核验日志挤掉，或核验重试把一笔消费打成两次。

整机实践上，云识客这类把算法做在终端里的厂家，三种场景可以共用模型，但队列、设备场景码、事件类型应三分。海康、大华通道与消费产线也长期分开账本，只是前端 OS 标签不同。

---

四、时钟比算法更先让离线人证翻车

证的有效期、日志先后、和后台对账都依赖时钟。开源鸿蒙终端断网后若时钟漂移，人证可能放行过期证，或拒绝仍有效的证。预研应写：NTP 源、离线最大允许漂移、漂移后是拒绝还是告警通行。这与「鸿蒙」一词无关，与嵌入式设备有关。

---

五、小结

在线离线人脸识别加身份证比对，要拆临时核验、正式名单、补传队列和时钟。鸿蒙人脸识别负责给出比对分；鸿蒙人脸识别消费机不要复用人证的离线队列。欢迎讨论：你们离线人证成功后，是否自动写入通行底库。