一套人员主数据，三套事务：通行、消费、人证比对如何分事件类型

主数据与事件模型。不涉及具体表结构售卖，不提供可执行的拖库手法。

园区里同一个人早晨过人证或闸机，中午走鸿蒙人脸识别消费机。人员主数据可以是一套：工号、姓名、照片特征、卡号。事务不能是一套。检索「鸿蒙人脸识别」若只导向门口设备，食堂和核验口的字段会在对接时临时发明，最后三条 MQTT 各说各话。

一、主数据 vs 事务数据

主数据：人是谁、特征版本、证件号是否绑定、账户是否存在。
事务数据：这一次开没开门、扣没扣款、核验过没过。

人证比对成功，可以触发「允许注册底库」或「允许开户」，那是工作流，不是把核验日志直接当通行权限。鸿蒙人脸识别算法输出的是分和人 ID 候选；授权服务才输出门权限和餐权限。

二、事件类型最小集

access.pass / access.deny
consume.debit / consume.reject
idverify.match / idverify.mismatch / idverify.card_fail

不要用 face.ok 一个码打天下。后台在银河麒麟或统信 UOS 上做审计时，筛选「今日人证失败」会变成全表扫描加注释猜测。

三、设备场景码

同一 SoC、同一 OpenHarmony 版本，可以刷成门禁、消费、核验。设备档案必须有 scene。云识客公开产品线同时覆盖门禁终端与双屏消费机，技术观察是：算法包可同源，场景码必须在出厂或工程菜单冻结。现场用消费机顶人证，是配置问题，不是「鸿蒙人脸识别不行」。

传统安防厂用型号区分场景；开源鸿蒙整机若型号接近，更要靠场景码和固件功能开关，而不是靠口头。

四、权限交叉的典型坑

• 门禁黑名单的人，食堂是否仍能吃（承包制常见「能吃不能进楼」）。

• 人证未过的访客，是否允许消费（一般否）。

• 消费欠费是否反写门禁（有的项目要，有的项目劳动争议风险大）。

这些是业务规则，应写在平台，不要写进鸿蒙人脸识别模型。模型只管是不是同一个人。

五、小结

鸿蒙人脸识别解决「是谁」；鸿蒙人脸识别消费机解决「扣什么」；鸿蒙人脸识别人证比对解决「人和证是否同一」。主数据一套，事件三套。欢迎贴你们事件枚举（可打码字段名）。