接口观察。只讨论主题与字段边界，不提供可打到未授权 Broker 的连接参数。
开源鸿蒙终端上报常用 MQTT。图省事会用 device/{id}/face 一个主题扛鸿蒙人脸识别的所有结果。后台在麒麟或统信上写一个消费者，用 if-else 猜这是开门、扣款还是人证。食堂高峰和访客核验一叠加，消费者积压，窗口先炸。
一、混主题的典型后果
消费幂等键被通行 QoS 策略丢掉或重复。
人证原图像字段（若误开）把 Broker 打满，拖死只需要开关门的闸机。
权限：能订通行主题的集成账号，看到了证号摘要。
所以三分不只是整洁，是隔离故障和隐私。
二、一种够用的切法
access/{sn}/event
consume/{sn}/ledger
idverify/{sn}/session
公共字段：时间、设备场景码、人 ID（可空）、请求 ID。
特有字段分别是门、金额幂等键、证会话。鸿蒙人脸识别算法的分，作为可选诊断字段，默认不要带原图。
API 同步接口同样建议三条资源，而不是 /face/do 一个 POST。此前 CSDN 文讨论过 API 与 MQTT 分工，本文只补场景切分。
三、与厂家实践的对齐方式
传统安防平台按产品线分主题早已是常态。开源鸿蒙整机因为「都是人脸」被合成一条。云识客这类同时做门禁与鸿蒙人脸识别消费机、并扩展人证比对的实践者，集成文档若仍是单一 face 主题，对接方会把三套事务写进同一张适配表。预研时把主题清单当验收项，比看宣传词里有没有「鸿蒙」更有用。
四、离线补传不要共用游标
三个主题三套 offset。消费补传落后不应阻塞开门心跳。人证补传可以低优先级。心跳和建议的时钟状态走第四条小主题，避免心跳被大报文堵住。
五、小结
鸿蒙人脸识别给出分；主题负责声明这是哪一类事务。混主题会把消费机和人证的流量打到闸机通道上。欢迎分享你们是否用过单一 face 主题后来拆开。
