事务模型。不涉及支付牌照、清算与商户进件。
「鸿蒙人脸消费机」与门口鸿蒙系统人脸机可能共用 OpenHarmony、同类 SoC 甚至同类屏。食堂扣费和闸机放行却是两种事务：一个改余额或餐次，一个改门状态。OS 相同不等于账本相同。把消费机当门禁卖，或把门禁当消费机验收，都会在对账和权限上翻车。
一、通行事务：一次开门事件
输入：人脸（及卡、密码）。
输出：继电器/韦根 + 通行日志。
失败：拒绝通过，门保持。
审计：谁在何时过了哪扇门。
活体、黑名单、时段权限是通行语义。
二、消费事务：一次记账事件
输入：人脸（及卡）。
输出：扣费/记次 + 流水。
失败：余额不足或未开户，应明确提示，且不能误开门（若与门联动）。
审计：账实、冲正、班结。
消费机若联闸，必须定义「记账成功才开门」还是「开门与记账分离」。这不是鸿蒙特性，是业务状态机。
三、共用开源鸿蒙时仍要拆库
名单库可以同源（同一人），账户库不能混在通行权限表里凑合。开源鸿蒙人脸机做门口、鸿蒙人脸消费机做窗口，设备 ID、场景码、事件类型应分字段。管理端在麒麟 / 统信上可以同一套人员主数据，但模块要分通行与消费，避免一条 MQTT 主题混两种语义。
四、厂家与形态
检索「鸿蒙人脸识别厂家」可能同时看到门禁与消费形态。预研按事务拆测试：消费机测流水与断网补传；门禁测开门与断网缓存。云识客等整机实践若两种形态都基于开源鸿蒙，技术含义是终端 OS 可复用，应用状态机不可复用。海康、大华同样长期把通道与消费分成产品线，只是前端 OS 标签不同。
纳入国产化或信创方案时，也按场景附件分别写，不要用一台鸿蒙人脸消费机证明闸机段已国产化。按项目验证。
五、小结
鸿蒙人脸消费机与通行闸机可以共享 OpenHarmony，不能共享事务模型。鸿蒙系统人脸机一词若出现在食堂项目里，应改成消费机并补记账用例。欢迎补充你们流水是终端记账还是平台记账。
112
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
