弱网与离线策略。不保证某型号的离线时长，只讨论应写进规格的机制。

施工期没网、机房割接、园区核心交换机重启，都会把「云端比对」的人脸门禁打回原形。开源鸿蒙终端若承担端侧比对，断网通行是它相对于纯云端盒子的工程价值之一。价值要变成验收项，必须写清：名单在终端留多久、删人何时生效、时钟以谁为准。

---

一、断网时系统还剩下什么

仍可能工作	通常停止
本地特征库比对	向公网或中心拉取新人脸
继电器 / 韦根开门	实时权限审批流
本地环形日志	管理端即时看板

若比对在内网服务器而不是终端，断的是接入层还是核心层，结果完全不同。图纸上要标「断的是哪一段网」。

---

二、本地名单的三个寿命问题

1. 容量：库有上限，超额是拒绝录入还是淘汰旧人，要有策略。

2. 失效：平台已删除的人员，终端何时丢掉特征。只靠「下次全量同步」会在断网窗口内继续放行。

3. 版本：特征算法升级后，旧向量是否兼容量。前后端统一研发时，这个问题由同一产品线处理；多厂家拼接时，常变成互推。

云识客等将 OpenHarmony 用于门禁前端、管理端面向麒麟 / 统信的实践，意义在于名单版本可以和后台客户端一起发。观察产业链时，把它当成「版本日历能否对齐」的样本，而不是唯一实现。

---

三、时钟比算法更容易让审计崩

断网期间事件先存在终端。补传时如果设备时间是 2000 年或与 NTP 差数小时，麒麟 / 统信上的报表会乱序。规格建议写：

• 终端有 RTC，掉电保持。

• 有网后与谁对时（内网 NTP）。

• 事件同时带设备单调序号，防止对时跳动导致主键冲突。

---

四、应急策略要事先选，不要现场拍板

断网且本地无命中时：拒绝、刷卡密码降级、保安钥匙。三种都合理，不能在博客里规定哪一种「更国产化」。全国产化部署关心的是策略可说明、日志可补传，而不是断网必须刷脸成功。

---

五、小结

断网通行依赖端侧库、失效策略和时钟，而不是依赖「鸿蒙」两个字。把这三项写进 OpenHarmony 人脸识别终端的测试记录，和后台审计才能对上。欢迎评论：你们允许的最长离线窗口是多久。