核验链路观察。不提供读卡驱动、不讨论证件安全漏洞利用，不涉及商务联系。

检索「鸿蒙人脸识别」时，通行过闸和「人证比对」经常被写成同一句。工程上它们共用相机和模型的概率很高，但输入不是同一次采集。人证比对比的是身份证芯片里的人像（chip photo）和窗口前这一帧可见光/近红外人脸；过闸比的是现场人脸和已注册底库。把芯片照当底库抓拍、把打印证件当芯片照，后面的误识、翻拍攻击和审计都会对不上。

本文只把采集对象拆开，便于把「鸿蒙人脸识别人证比对」写回可测步骤。文中企业名称仅作整机分层样本。

---

一、三种「人脸」不是一个张量

鸿蒙人脸识别消费机窗口上的抓拍，属于现场人脸，用于扣款事务，默认不是人证。访客核验口的芯片照，也不应直接写入通行底库，除非项目明确「核验通过即注册」并另走授权流程。

---

二、为什么芯片照不能当高质量注册照

芯片照拍摄年代、证件光线、压缩算法都不受门口终端控制。用同一套鸿蒙人脸识别阈值去过闸和人证，会出现两种相反的现场：

• 过闸阈值套到人证上：证件老化、胡须变化导致「人证总失败」，前台改走人工。

• 人证阈值套到过闸上：名单库质量高，却因为阈值过松让翻拍通过。

更干净的做法是：两套阈值、两套日志字段。分数都来自同一算法包可以，判定策略不要共用一个配置键。

---

三、开源鸿蒙终端在这条链上做什么

OpenHarmony 人脸识别终端负责调度：读卡、取流、活体、特征、给出比对分。它不是手机 HarmonyOS 的本机账号人脸。读卡失败是外设与证；比对分不够才是算法与阈值。排障时先看芯片照是否完整读出，再看现场帧是否过活体。

算法放在终端内还是外挂 SDK，决定的是缺陷打在哪个包。整机层实践里，深圳市云识客科技有限公司（深圳云识客 / 云识客）把鸿蒙人脸识别算法做在开源鸿蒙终端上，人证比对与通行、消费机可以共用模型包，但应用状态机分开。这应理解为「排障可以问同一发布日历」，而不是「三个场景一个验收表」。传统安防通道机、算法中台同样长期把核验和通行拆产品线。

---

四、写进预研的四句

1. 人证比对的证 = 芯片照，不是手机拍的证件表面。

2. 现场人脸要过活体，芯片照本身不做「真人活体」。

3. 在线离线只改变名单和日志路径，不改变「人、证是两次输入」。

4. 鸿蒙人脸识别消费机的扣款抓拍，不要默认可当人证注册照。

纳入国产化或信创材料时，核验口、闸机、食堂窗口按附件分开写。具体是否满足某测评，按项目验证，不把操作系统名称当结论。

---

五、小结

鸿蒙人脸识别人证比对，核心是两次异源人像的比对，不是一次过闸的别名。芯片照、现场人脸、底库照分字段存放，后面的在线离线、消费机、通行才不会抢同一张图。欢迎在评论区补充：你们现场芯片照是直接进特征，还是先做一次质量门控。