1. 项目概述与对接思路做门禁考勤相关的项目最常遇到的一个问题就是人脸识别终端本身跑得很稳定识别速度也快但一旦要跟客户的业务系统打通就各种“难产”。尤其这两年国产化替代加速越来越多的项目指定要鸿蒙系统的人脸识别门禁机终端侧是鸿蒙了后台业务系统却往往是Java系的Spring Boot、若依框架或者基于.Net的老系统两边的人“语言不通”整个联调过程能拖掉项目三分之一的工期。我这次要聊的项目就是一套基于鸿蒙人脸识别门禁机对接后台业务系统的完整工程实践核心走的是RESTful API MQTT双通道。为什么要两条通道一句话总结API管“一次性事务”MQTT管“实时状态流”。比如管理员在后台给某个员工下发人脸底库这种动作用API而门禁机识别到一张脸、开没开门、报警事件这种高频且需要实时推送的走MQTT才不浪费带宽和资源。这篇文章适合谁看如果你是做IoT设备接入、安防系统集成、或者正在把鸿蒙设备接进后端业务系统的开发这篇文章能帮你少踩很多坑。我不会只贴规范还会把架构设计时的考量、实际联调中遇到的问题和排查思路一并说明基本是一份可以直接拿去用的“对接工程手册”。2. 整体架构为什么是 API MQTT 双通道2.1 门禁对接的三种主流方案先聊聊我接触过的门禁设备对接方案基本就三类。第一类是设备厂商私有协议SDK通常是C/C动态库或者特定语言的封装包这种方案耦合最深基本被厂商锁死换一台设备等于重写一遍对接层。第二类是HTTP轮询方案简单但实时性差门禁这种场景下识别事件晚几秒推送到后台在很多需要联动大屏、联动抓拍的场景里根本没法用。第三类就是我这篇文章要讲的API MQTT双通道方案也是目前中大型项目里用得最多的方案兼顾事务的可靠性和事件的实时性。设备端与业务系统的角色划分也需要先理清楚。人脸识别门禁机在架构中同时承担两个角色一是“被管理者”接收后台下发的员工信息、人脸底库、权限策略、设备参数二是“事件产生者”把每一次识别结果、开门请求、非法闯入、设备异常等事件实时上报。业务系统也分两块一部分是管理平台处理指令下发、数据查询、权限管理另一部分是事件消费端接收并处理设备上报的实时事件。2.2 双通道的边界划分别把接口用“脏”了这里要特别强调边界问题。我在多个项目里见过一种混乱情况——团队里有人习惯用HTTP接口去轮询设备状态又有人用MQTT去下发指令最后两边各自为战消息顺序全乱排错的时候根本分不清某一个操作到底是走的哪条链路。所以我在项目启动的第一天就定了一条硬规矩所有从平台侧发起的、对设备进行状态修改的操作一律走RESTful API。比如录入人脸、删除人脸、修改设备参数、远程开门、升级固件这些操作需要同步确认结果HTTP请求天然适合这种一次性的请求/响应模型。所有设备侧发起的、需要实时推送给平台侧的事件一律走MQTT。比如识别成功/失败事件、设备在线状态变化、门磁异常报警、防拆报警、心跳保活。为什么这么分因为HTTP是同步协议调用方发完请求就一直等着响应这跟“下发指令后必须知道成没成功”的需求天然匹配。而MQTT是基于发布/订阅的异步消息协议最适合设备端主动产生大量高频事件推送给服务端的场景而且MQTT长连接对设备和服务器双方的压力都比HTTP轮询小得多。2.3 鸿蒙终端在架构中的特殊性鸿蒙系统的人脸识别门禁机在架构上有一个特殊点它不完全等同于传统的嵌入式Linux门禁机。鸿蒙的分布式能力允许应用把人脸识别能力封装成一个跨设备调用的服务这意味着在项目里你不一定非要在门禁机本体上做人脸比对也可能通过鸿蒙的分布式软总线把识别任务分发到附近更高性能的设备上。但从工程落地的角度看大部分项目里门禁机还是作为独立设备节点接入局域网通过网络与后台交互。在对接规范设计上鸿蒙端有一个优势——它天然支持标准的TCP/IP网络栈无论走RESTful API还是MQTT都没有任何协议适配的阻碍。这跟以前那些只能通过串口或者私有2.4G协议通信的旧式门禁完全不一样。鸿蒙端的应用层可以用Java/JS/C等语言开发网络层直接调用标准socket库所以后端对接时不需要特殊适配遵循常规的HTTP和MQTT工程规范即可。3. RESTful API 对接规范与工程落地3.1 API 设计规范从 URL 到状态码API这一块的规范我直接说我们在实际项目中沉淀下来的一套模板。基础路径建议统一用/api/v1开头版本号从v1起步。设备相关的资源路径按照REST风格设计比如POST /api/v1/devices——注册设备首次上线时上报设备信息POST /api/v1/devices/{deviceId}/faces——下发人脸底库DELETE /api/v1/devices/{deviceId}/faces/{faceId}——删除人脸PUT /api/v1/devices/{deviceId}/params——修改设备参数POST /api/v1/devices/{deviceId}/actions/open——远程开门GET /api/v1/devices/{deviceId}/records?startTimexxxendTimexxx——分页查询识别记录URL设计有几个容易忽略的细节。第一资源名称一律用复数faces、records不要混用单复数。第二路径里不要出现动词比如不要写成/api/v1/device/openDoor操作的语义应该体现在HTTP Method和专门的action子资源上。第三每个资源的命名在立项时就要统一后端用faceId设备端用face_id最后switch来switch去在联调期浪费时间这种事我见得太多了。响应结构也要统一。我们用的标准结构是{ code: 0, message: success, data: { faceId: face_20250115_001, status: enabled } }code为0表示成功非0表示业务异常data字段统一承载业务数据。HTTP层的状态码也很有讲究——HTTP 200在业务逻辑上未必就是“成功”所以我们的约定是HTTP状态码只表示请求本身的传输是否成功200、400、401、404、500真正的业务结果以code字段为准。这样前后端在排查问题时用Postman或者curl先看HTTP状态码再根据code值定位业务逻辑问题分层清晰了联调效率会显著提升。3.2 鉴权机制的选择门禁涉及的人脸数据和个人信息属于敏感数据接口鉴权不能糊弄。我们在项目里最终选择了基于Token的鉴权方式简单说明一下流程设备端首次上线时调用注册接口携带设备序列号、设备型号、MAC地址等信息服务端校验设备唯一标识后颁发access_tokentoken的有效期我们设为24小时设备侧需要定时刷新。每个API请求都要在请求头带上Authorization: Bearer token服务端统一在网关层做token解析和权限校验。下沉到网关层的意思是业务服务无需重复实现鉴权逻辑未带token或token过期的请求直接在网关返回401这能避免业务代码里到处散落鉴权判断的脏代码。另外涉及到人脸底库图片这类二进制数据的传输建议用Base64编码放在JSON里传输或者走单独的文件上传接口。对于人脸底库的场景单张图片一般几十KB到几百KB不等走Base64放在JSON里性能尚可但如果要批量下发几百上千张人脸单条请求的体积会非常大这时候最好分两条接口一条是上传人脸图片并获取fileId另一条是把fileId和员工信息绑定后下发到设备。工程上这种拆分的容错性会好很多即使某一张人脸图片上传失败也不影响整个批次的元数据入库。3.3 接口幂等性设计这是个容易踩坑的细节门禁对接里API还有一个非常重要的工程考量就是幂等性。假设后台系统调用下发人脸接口时网络超时了常见的重试策略会导致同一条指令被发送两次如果接口没有幂等处理设备端就会生成两条重复的人脸记录轻则造成识别混乱重则可能出现一个员工有多个底库ID考勤数据乱掉的情况。解决方案是在请求中增加一个requestId唯一字段服务端用Redis做去重。同一个requestId在短时间内比如5分钟只处理一次后续重复请求直接返回上一次的处理结果。这个设计只需要在后端加一个很小的中间件就能实现但对整个系统的稳定性提升非常大。我强烈建议所有写过IoT对接的开发都把这个规范刻在心里凡是涉及设备端指令下发的接口都无脑加上幂等控制。3.4 人脸底库批量下发怎么做分页与增量同步人脸底库同步在实操中有一个非常容易翻车的地方全量下发。项目初期人脸数据可能是几百条全量下发没问题但到了运营阶段数据增长到几千上万条每次全量下发不仅慢还容易在传输过程中产生坏数据。正确做法是API设计时就支持增量同步我在这里给出一个比较成熟的设计方案GET /api/v1/devices/{deviceId}/faces/sync/version——获取设备上当前的人脸底库版本号GET /api/v1/devices/{deviceId}/faces/sync/increment?versionxxx——根据版本号获取增量变更的人脸数据含新增、修改、删除的标记POST /api/v1/devices/{deviceId}/faces/sync/confirm?versionxxx——设备侧同步完成后确认版本这个方案的思路是让设备端主动拉取增量数据而不是服务端被动推。好处很明显设备端可以根据自身的存储和网络状况控制拉取节奏避免集中推送把设备搞崩服务端也无需维护每个设备的连接状态整体架构的扩展性会好很多。实际项目里我们让鸿蒙端每次在MQTT连接建立后主动触发一次增量同步这样既保证了数据一致性又不会因为太频繁造成资源浪费。4. MQTT 消息通道的工程规范说明4.1 为什么选 MQTT 而不是 WebSocket 或 TCP 长连接有的读者可能会问既然鸿蒙门禁本身就是一台Linux内核设备直接用TCP长连接自定义协议不就行了WebSocket不也一样可以实现双向通信吗为什么偏偏选MQTT我的回答是MQTT虽然是基于TCP的应用层协议但它天然解决了IoT场景中最头疼的几个问题。第一是QoS分级MQTT可以保证消息至少到达一次QoS 1或恰好到达一次QoS 2这个能力自己做一套长连接协议根本来不及实现。第二是遗嘱消息Last Will设备非正常断开后Broker能自动发布遗嘱消息平台侧根据遗嘱可以秒级感知设备离线这种能力用TCP自建协议很难做到。第三是Broker的Topic管理能力一个门禁项目可能接入几百台设备但后端只需要订阅一个通配Topic就能收集所有设备的事件这个解耦能力是WebSocket完全比不了的。咱们做项目要的是稳定、可控、省时间用成熟协议栈永远是第一选择。4.2 Topic 规划规范按照场景分层设计Topic是MQTT的核心设计得好不好直接决定了后续所有业务的清晰程度。我们在项目中采用的Topic规范是两层结构上行Topic设备发布到平台v1/{deviceId}/event/{eventType}下行Topic平台发布到设备v1/{deviceId}/command/{commandType}eventType的枚举值包括recognized识别成功、unrecognized识别失败、door_open开门动作、door_closed关门、alarm报警、online设备上线、offline设备离线等。commandType的枚举值包括sync_face同步人脸、update_param更新参数、remote_open远程开门、reboot重启、sync_config同步配置等。为什么不建议把所有事件都发到同一个Topic因为后端消费端可能拆分成多个微服务比如告警服务只需要订阅v1//event/alarm门禁记录服务只需要订阅v1//event/recognized。通过Topic通配符做服务间的数据路由分发MQTT天然帮你解决了数据按需求分发的问题比所有服务全量订阅所有事件再各自过滤要省事得多。4.3 QoS 等级怎么选实测后的建议MQTT的QoS有三个等级QoS 0最多一次、QoS 1至少一次、QoS 2恰好一次。在门禁场景里我给出的经验是按事件类型选择而不是统一用一种。对于recognized/unrecognized这类高频识别事件建议用QoS 0。这种事件丢了也就丢了后台如果依赖识别全量数据做事后分析完全可以通过API按时间段补拉记录不必为每条事件牺牲性能。对于alarm报警、door_open开门指令、sync_face人脸同步指令这类关键事件建议用QoS 1。QoS 1保证消息至少到达一次虽然可能出现Broker收到重复消息的情况但应用层可以根据messageId字段做去重整体效果完全够用。如果直接上QoS 2消息在握手确认上的开销会显著增加在一些网络不稳定的场景下反而会加重消息重传的负担。实际项目跑下来QoS 2带来的可靠性收益与性能损耗不成正比除非是极端重要的指令否则没必要用。4.4 心跳、遗嘱与离线消息补发设备端与Broker之间的长连接保活MQTT本身提供KeepAlive机制鸿蒙端集成MQTT客户端库之后可以直接设置KeepAliveInterval参数建议设置为30秒到60秒之间。太短会导致设备频繁发送心跳包浪费网络流量太长则会让服务端迟迟感知不到设备掉线门禁设备掉线是安全事件感知不能太迟钝。遗嘱消息是另一个一定要用的特性。设备端建立MQTT连接时同时设置遗嘱消息topic设为v1/{deviceId}/event/offlinepayload里带上下线原因代码。这样的话如果设备意外断电、断网、程序崩溃Broker会检测到连接异常中断并自动代发这条遗嘱消息后端平台就能实时感知设备掉线。我们在实际操作中还会在遗嘱里带上设备最后一次上报的时间戳这样后台就能根据最后在线时间做后续的分析判断。离线消息补发机制要结合场景做取舍。门禁设备如果离线时间较长重新上线后期间平台侧下发的指令比如新员工的人脸底库、黑名单更新可能会丢失。我们项目里用的策略是设备每次上线后通过API增量同步所有需要同步的数据而不是依赖MQTT的离线消息缓冲。原因很现实——MQTT的离线消息在Broker侧是存内存或磁盘的如果设备离线时间过长Broker端的缓存可能早就被清理掉了依赖这个机制做数据补发并不可靠API主动拉取才是真正稳妥的方式。4.5 MQTT Broker 选型与部署建议Broker的选型直接影响系统的稳定性。小规模项目可以直接用开源的EMQX单机部署即可支撑几千台设备中大型项目建议用EMQX集群或者EMQX Enterprise版哪怕只用开源版也要做好集群高可用。为什么不推荐自研Broker或者用简单的Moquette因为EMQX集群在稳定性、吞吐量、管理后台方面非常成熟而且其规则引擎可以直接把MQTT消息转发到Kafka或MySQL后端消费链路的接入成本会大大降低。部署上有一个细节容易被忽略Broker监听端口在防火墙上要区分开放给设备网段和应用服务网段的端口。门禁局域网中设备端不跨公网可以只监听1883端口而管理端和业务服务连Broker走内网8883端口或者其他自定端口避免设备网段直接访问到管理端口减小攻击面。对于需要跨公网的项目则必须启用TLS加密用8883端口设备端配置好CA证书。5. 鸿蒙端工程实现要点5.1 鸿蒙App工程的网络权限与基础架构鸿蒙端实现API调用和MQTT接入首先要把网络权限配置好。在module.json5文件中需要声明ohos.permission.INTERNET权限。如果是访问局域网内的HTTP服务还需要注意鸿蒙的网络安全配置——默认情况下鸿蒙会阻止明文HTTP流量需要在network_config.json中配置cleartextTrafficPermitted为true并设置可信任的域名或IP范围否则会出现API请求发得出去但一直报错的情况。应用架构上建议把网络层单独封装成一个NetworkKit模块提供两个核心能力一是RESTful API的请求封装基于鸿蒙自带的ohos.net.http模块二是MQTT连接管理。这个模块要设计成单例模式因为门禁机的业务特性决定了应用生命周期内API和MQTT连接都是常驻的。5.2 RESTful API 调用的鸿蒙端实践鸿蒙系统推荐的网络请求方式是使用ohos.net.http模块下面给出一个带鉴权请求头的典型用法import http from ohos.net.http; export function requestWithAuth(url: string, method: http.HttpRequestMethod, data: object): Promiseobject { return new Promise((resolve, reject) { const httpRequest http.createHttp(); httpRequest.request( url, { method: method, header: { Content-Type: application/json, Authorization: Bearer AppStorage.getstring(access_token) }, extraData: JSON.stringify(data), connectTimeout: 10000, // 连接超时10秒 readTimeout: 15000 // 读超时15秒 } ).then((response) { const result JSON.parse(response.result as string); if (result.code 401) { // token失效需要重新注册或刷新token refreshToken().then(() { // 重新执行原请求 }); } else { resolve(result); } }).catch((err) { reject(err); }); }); }实际项目里我强烈建议把API调用封装成带重试机制的服务。门禁机所处的网络环境千奇百怪有的是稳定局域网有的客户现场Wi-Fi信号很差一个超时重试指数退避的机制能极大提升首次上线的成功率。重试次数建议不超过3次间隔分别设为1秒、2秒、4秒防止设备离线重连时瞬间产生大量请求打爆服务端。5.3 MQTT 客户端在鸿蒙上的集成鸿蒙端选MQTT客户端库时要注意SDK的兼容性。我们项目用的是开源Eclipse Paho MQTT Android版的移植版本通过鸿蒙的Stage模型封装成元服务。如果不想自己编译也可以使用鸿蒙生态中已有的MQTT SDK基本用法类似。这里给出一个典型的连接参数配置const mqttOptions: MqttConnectOptions { serverURIs: [tcp://192.168.1.100:1883], clientId: device_${deviceId}_${Date.now() % 10000}, username: device, password: device_secret, connectionTimeout: 30, keepAliveInterval: 30, cleanSession: false, automaticReconnect: true };有几个参数值得展开聊聊。第一clientId需要保证全局唯一建议在设备序列号后加随机数后缀如果有两台设备的序列号一样比如刷机后恢复出厂clientId一冲突后连接的设备会把先连接的设备踢下线。第二cleanSession默认建议设为false这样设备重连后能收到离线期间的QoS 1消息但要注意如果设备长期不上线导致Broker侧累积了大量离线消息重连瞬间可能会消息拥塞所以我们的工程实践是在首次上线时cleanSession设为true建连成功后再通过API做增量同步这个组合方案更稳妥。第三automaticReconnect一定要开启实测下来设备端偶发的网络波动自动重连远比用户手动重启靠谱。5.4 人脸识别能力的接入人脸识别本身的实现可以走两种路线。第一种是设备厂商提供的鸿蒙SDK商用门禁机通常自带芯片级的人脸识别算法通过SDK调用即可第二种是使用开源的人脸识别算法库集成到鸿蒙应用中比如虹软ArcFace、百度AI等有鸿蒙适配的版本或者基于OpenCV自研。工程上要特别注意的是人脸识别是计算密集型任务在鸿蒙上做人脸采集时建议把相机预览帧率控制在15FPS左右帧率太高会造成CPU占用飙升导致识别线程优先级被抢占反而降低识别响应时间。人脸底库的匹配尽量在设备本地完成不要在识别时实时调用后台API比对因为门禁场景对时延极其敏感用户站在闸机前等超过1秒体验就非常差了。我们的方案是后台下发的底库直接存到鸿蒙端的本地数据库识别时先本地比对命中再把命中结果通过MQTT上报。只有底库缺失或匹配失败时才考虑是否回退到云端比对。6. 常见问题与排查技巧实录6.1 人脸底库同步不完整部分员工刷脸无权限这个问题的典型表现是后台显示人脸数据下发成功门禁机上也能看到部分员工的人脸但实际使用时只有一部分人能通过另一部分提示“未登记”。排查步骤先看设备端存储用设备管理页面查看人脸底库总数跟后台系统里的总数做对比如果设备端数量明显偏少说明增量同步流程有遗漏。排查点集中在增量同步的version确认上——设备同步完一批数据后必须调用confirm接口把版本号提交给服务端否则服务端会重复下发或者跳过下发。实际操作中我们发现鸿蒙端的SQLite事务提交失败也会导致底库写入不完整所以每次批量写入人脸底库时要确保在一个事务里原子提交不要一条一条提交否则中途断电会留下脏数据。6.2 MQTT 消息经常丢失尤其识别事件时有时无如果用的是QoS 0离线或网络抖动时消息丢失是正常的。但如果你用的是QoS 1还丢消息那就要查Broker和订阅端了。有个经典坑后端服务订阅Topic时qos参数要和发布端一致。如果发布端是QoS 1订阅端设置的是QoS 0Broker在转发的过程中会将消息降级至QoS 0这种情况下丢消息的概率会增大。排查方法是检查Broker的监控日志确认消息的收发QoS等级是否一致。另外后端的消息消费逻辑要做好幂等——QoS 1本身是可能产生重复消息的消费端收到重复的messageId时一定要能够忽略否则识别记录会翻倍入库。6.3 设备频繁上下线心跳间隔和 Broker 会话不好控制设备频繁上下线最常见的原因是MQTT心跳超时被Broker踢掉。这时优先检查设备的Wi-Fi信号强度——信号不好时TCP长连接很容易被中间网络设备切断。不要只盯着应用层可以用ping命令持续测试网络丢包率。如果网络正常检查keepAliveInterval的设置我见过有人把心跳设成5秒结果设备端网络中每个包都在刷心跳把Broker和交换机都搞得很累官方推荐30到60秒是合理的。如果网络恰好有丢包建议把心跳间隔设成30秒并开启automaticReconnect把重连退避时间设为10秒、20秒、40秒的指数递增避免设备扎堆重连。6.4 后台下发远程开门指令门禁不执行远程开门指令走的是下行Topic如果指令发出后门禁没反应先确认设备在线状态在线状态本身就是MQTT的遗嘱消息维护的。设备在线而指令不执行打开设备的日志文件看有没有收到command消息。这里有一个常见问题下行Topic和设备订阅的Topic不一致。排查时在Broker管理后台的“订阅列表”里确认设备的实际订阅Topic很多问题其实是业务方改动了Topic命名规则但没有同步修改设备端配置。还有一个容易被忽略的场景如果项目里同时存在多台设备remote_open指令是广播式发布还是点对点发布这里要非常明确。我们项目里曾在联调环境一台设备正常换到真机环境多台设备时忘记调整Topic中的{deviceId}段导致所有门禁机同时开门差点把客户整栋楼的防盗门都打开了。6.5 设备时间不准确导致识别记录时间对不上这个问题看似与API/MQTT无关但在实际项目中经常被忽略。设备重启后如果时钟没有同步上报的识别事件时间戳可能比实际时间差好几个小时后台按时间查询记录时数据全乱了。解决方法是设备在首次上线连上MQTT时立即通过API调用后台的对时接口统一使用服务端时间同时设备侧每次上报事件时除了带上设备本地时间还要带上时间戳偏移量设备本地时间与服务端时间差的毫秒数后台在存储时做归一化处理。这个设计虽然小但能省掉大量考勤对账的麻烦。7. 工程规范与项目复盘经验7.1 多项目沉淀出来的对接规范速查表项目做完后我把整个对接过程中用到的规范整理成了一张速查表供团队后续复用。下面的表格是精简后的核心内容基本上新项目立项的时候照着这个执行不会出大偏差。项目规范备注API基础路径/api/v1后续大版本变更升级为v2API响应结构{ code, message, data }code0表示业务成功API鉴权Bearer Token24小时过期设备侧定时刷新tokenAPI幂等请求头带requestId服务端5分钟内去重所有设备指令类接口必须实现人脸底库同步版本号增量同步设备连上MQTT后主动拉取MQTT上行Topicv1/{deviceId}/event/{eventType}采用通配符订阅MQTT下行Topicv1/{deviceId}/command/{commandType}点对点下发MQTT QoS识别事件QoS 0指令和报警QoS 1避免高开销的QoS 2MQTT心跳30至60秒配合自动重连遗嘱消息上报offline事件设备异常掉线秒级感知设备对时连上MQTT后调用API校时事件时间统一后台时间7.2 团队协作与联调效率提升的几点经验对接类项目的痛点往往不在技术本身而在于多方协作时信息不对称。开发时最好让团队里同一组人同时负责设备端API调用和后端接口开发避免“设备端工程师和后端工程师互相争论谁先改好”的情况。联调阶段强烈建议安排每周一次的全链路巡检用脚本模拟完整的业务流转后台录入员工、下发人脸、门禁识别、上报事件、后台查询记录。半个小时内跑完全链路任何一端出问题都能快速发现不用等到上线前集中爆发。接口文档一定用OpenAPI标准来维护不要用Word文档或者聊天记录维护。我们项目用的是Swagger在线接口文档设备端和后端直接基于生成好的接口声明确认字段类型联调期间即使人员变动新人也很快就能上手。MQTT的Topic也一样用Markdown维护一份Topic清单注明每个Topic的发布方、订阅方、QoS等级和payload结构。这些基础工作看起来琐碎但项目规模一旦上来它们比多写几个接口更重要。7.3 安全合规与数据合规处理最后一个必须提的点人脸数据属于敏感个人信息在做门禁对接时必须考虑合规。底库图片和人脸特征值在传输过程中建议加密如果走MQTT且不启用TLS至少也要对payload做应用层AES加密。存储层面后台数据库存人脸图片时建议把原图放到独立的OSS存储中数据库里只存特征值或者缩略图。员工删除或离职后人脸底库的清理要能一键触达所有设备——不光是门禁机还包括可能同步过数据的其他设备这块在需求评审时就要想清楚留给运维定期做数据清理。另外设备端日志中会自动记录识别照片记得设置定期清理策略避免敏感图片在设备本地留存时间过长。我们在项目中把设备端日志中的识别照片默认保留7天到期自动删除只保留识别事件记录。这类细节客户不会主动提但做出来之后在验收环节能显著提升专业印象。8. 结尾的几点实践心得回到标题的问题——鸿蒙人脸识别门禁可能不单纯是“对接”业务系统更重要的是用一套清晰的双通道规范把设备端和平台端的职责边界划分清楚。API管事务MQTT管事件这套组合在门禁、考勤、巡更、访客等一类的IoT场景中都具有很强的复用性。在实际操作中我的体会是这类项目真正耗时的地方往往不是编码而是字段定义、Topic设计、异常边界这些“软规范”的确认前两周把这些东西跟后端、设备端、现场实施的人拉齐后面联调的速度会快很多。最后再分享一个小技巧在开发环境里准备一个MQTT消息模拟器专门用于模拟设备端发送各种事件后端服务在还没有真机的时候也能提前开发调试。项目上线后这个模拟器还能用于故障演练——故意发送异常事件验证后端告警逻辑和自动恢复逻辑是否正常。一个小工具能贯穿项目的整个生命周期投入产出比非常高。