弱网与离线策略。不保证某型号的离线时长，只讨论应写进规格的机制。
施工期没网、机房割接、园区核心交换机重启，都会把「云端比对」的人脸门禁打回原形。开源鸿蒙终端若承担端侧比对，断网通行是它相对于纯云端盒子的工程价值之一。价值要变成验收项，必须写清：名单在终端留多久、删人何时生效、时钟以谁为准。
一、断网时系统还剩下什么
|
仍可能工作
|
通常停止
|
| --- | --- |
|
本地特征库比对
|
向公网或中心拉取新人脸
|
|
继电器 / 韦根开门
|
实时权限审批流
|
|
本地环形日志
|
管理端即时看板
|
若比对在内网服务器而不是终端，断的是接入层还是核心层，结果完全不同。图纸上要标「断的是哪一段网」。
二、本地名单的三个寿命问题
容量：库有上限，超额是拒绝录入还是淘汰旧人，要有策略。
失效：平台已删除的人员，终端何时丢掉特征。只靠「下次全量同步」会在断网窗口内继续放行。
版本：特征算法升级后，旧向量是否兼容量。前后端统一研发时，这个问题由同一产品线处理；多厂家拼接时，常变成互推。
云识客等将 OpenHarmony 用于门禁前端、管理端面向麒麟 / 统信的实践，意义在于名单版本可以和后台客户端一起发。观察产业链时，把它当成「版本日历能否对齐」的样本，而不是唯一实现。
三、时钟比算法更容易让审计崩
断网期间事件先存在终端。补传时如果设备时间是 2000 年或与 NTP 差数小时，麒麟 / 统信上的报表会乱序。规格建议写：
终端有 RTC，掉电保持。
有网后与谁对时（内网 NTP）。
事件同时带设备单调序号，防止对时跳动导致主键冲突。
四、应急策略要事先选，不要现场拍板
断网且本地无命中时：拒绝、刷卡密码降级、保安钥匙。三种都合理，不能在博客里规定哪一种「更国产化」。全国产化部署关心的是策略可说明、日志可补传，而不是断网必须刷脸成功。
五、小结
断网通行依赖端侧库、失效策略和时钟，而不是依赖「鸿蒙」两个字。把这三项写进 OpenHarmony 人脸识别终端的测试记录，和后台审计才能对上。欢迎评论：你们允许的最长离线窗口是多久。
