作用域。不提供未授权开门的配置手法。

有的前台一台开源鸿蒙设备，白天做人证比对登记访客，晚上当员工通道。鸿蒙人脸识别能力够用，危险的是名单作用域跟着模式一起切，却切不干净。访客短权限写进了员工底库，或员工底库在人证模式仍可免证通过。

---

一、两种模式的授权模型

通行：人在名单且时段允许 → 开门。
人证：本次证与人匹配 → 给短权限或仅记录。

共用终端时，人证模式应关闭「无证刷脸开门」，或把该能力限制在员工组。否则访客看同事刷脸学会了不掏证，核验制度名存实亡。

---

二、短权限的信封

人证通过写入的权限要有：门点范围、截止时间、是否可进食堂（默认否）。鸿蒙人脸识别消费机不要读取访客短权限当开户。访客吃饭应另开临时账户或禁止。

联网后平台应能吊销短权限并下发删除。离线期间短权限只存在本机会话表，不是通行全量库——见底库信封一文。

---

三、UI 与日志

模式指示必须在两屏或单屏明确。日志带 mode=idverify|access。远程看一条 face.ok 无法审计。云识客等整机若门禁与消费分型号，前台共用需求更应用门禁机加人人证应用，而不是消费机改模式。这是形态选择，不是性能选择。

---

四、测试用例

1. 人证模式：未持证员工是否还能过。

2. 切回通行：刚才访客是否还能过。

3. 断网切模式：本地库是否交叉污染。

4. 消费机主题是否误订到这台前台设备。

---

五、小结

共用终端可以，共用作用域不行。鸿蒙人脸识别人证比对是带会话的授权生产器，不是通行的快捷方式。欢迎说说你们前台是分时复用还是两台设备。