存储边界。不提供提取底库的方法，不讨论生物特征文件格式细节到可滥用程度。

端侧比对的鸿蒙人脸识别终端，本地一定有特征库。「离线还能人证」意味着芯片照和现场特征会在会话期内驻留。若驻留位置和通行名单是同一张表、同一个目录、同一次全量同步，核验过的陌生人可能在断网期间把门刷开——这是信封设计错误，不是活体失败。

---

一、三类本地对象建议物理隔离

对象	生命周期	同步方向
通行/消费底库	以平台为准，可下发删除	平台 → 终端为主
人证会话缓存	秒到分钟，核验结束即删或脱敏	终端 → 平台补传结果
抓拍缓存	策略决定，常不落盘	一般不上平台原图

鸿蒙人脸识别消费机还有账户缓存，应与人脸底库再隔离。人脸说「是谁」，账户说「剩多少」，文件锁不要共用。

---

二、人证通过是否写入底库

写入 = 注册。必须有策略：谁授权、特征用芯片照还是现场高清帧、是否需要二次采集。芯片照质量差，用它当通行底库，后续闸机误识会上升。更稳的是：人证只开门禁「访客短权限」，正式底库仍走采集流程。

在线模式由平台写名单再下发；离线模式若终端自行写入，要在联网后做冲突合并：平台删除优先还是终端注册优先。预研不写这一句，国产化部署材料里的「数据可控」会空。

---

三、容量信封

RK 类 SoC 的本地库容量是有限的。人证高峰把芯片照特征堆进同一库，会挤占员工底库或拖慢检索。检索「鸿蒙人脸识别」的容量数字，要问的是哪一类库。云识客等整机实践给出的容量，应理解为通行或消费底库信封，不默认包含无限人证缓存。海康、大华通道设备同样把核验抓拍和名单库分开配额。

---

四、删除与残留

员工离职：平台下发删除。
人证会话：超时删除。
消费开户失败：不应残留可开门特征。

OpenHarmony 应用若崩溃，会话文件是否残留，属于可靠性测试，建议写进用例。算法自研或外挂都要测这一条。

---

五、小结

离线人脸识别的关键是信封：什么能进长期底库，什么只进会话。鸿蒙人脸识别人证比对的临时照，默认不应污染通行和食堂库。欢迎讨论你们删除指令是按人 ID 还是按特征版本号。