干集成商这一行有年头了人脸识别门禁项目前前后后也交付了不少。以前遇到的大多是安卓方案这两年明显感觉到了变化越来越多的项目方在招标时点名要鸿蒙系统的人脸识别门禁机尤其是园区、办公写字楼和部分对国产化有要求的单位。上个月刚完成一个办公园区的人脸识别门禁项目验收40多个点位用的就是鸿蒙系统设备测试过程中踩了不少坑也整理出一套还算顺手的验收流程和方法。这篇文章就把这套针对鸿蒙人脸识别门禁项目的验收与性能评估清单完整分享出来。不管你是集成商同行、项目施工方还是甲方信息化部门负责验收的人都可以直接拿这份清单去对项目、跑测试、出报告。文章还会把每个评测项为什么要测、怎么测、用多少样本、判多少分算合格都讲清楚而不是只给你一张干巴巴的表格。1. 项目验收到底在验收什么1.1 先从合同里抠出验收依据做验收第一步不是开设备而是把合同、招标文件、技术方案里的功能要求和性能指标全部翻出来逐条列成一份《需求追溯表》。很多项目验收扯皮根源就是需求没对齐甲方说“识别要快”乙方说“已经很快了”最后谁也说不清。从我经手的项目看一份合格的验收依据至少要包含四类内容功能需求人脸识别开门、刷卡/密码开门、远程开门、访客管理、考勤记录、陌生人报警等。性能需求识别时间、识别率、误识率、活体检测能力、并发处理能力。系统需求操作系统版本这里就是鸿蒙、设备联网方式、数据上报接口、离线缓存能力、OTA升级能力。环境需求工作温度范围、防护等级IP等级、安装方式、供电方式。拿到这些之后再把它拆成可测试、可量化的验收项。比如“识别时间”就要明确是设备端人脸比对时间还是刷卡到开门的完整时间“识别率”就要明确是在多少人脸库容下测试、多少人测试、测试多少次。这里有一个特别容易被忽视的点鸿蒙系统设备的功能实现方式和安卓设备并不完全一样。比如鸿蒙设备上的人脸识别应用可能是HarmonyOS的元服务或原子化服务形态安装包是HAP格式而不是APK。验收时要确认甲方要求的“鸿蒙版”是原生鸿蒙应用还是套了鸿蒙壳的安卓应用。我遇到过项目验收时甲方较真专门查了设备上的应用包格式发现是安卓APK转过来的最后要求厂商重新出了原生鸿蒙版本才通过验收。这件事建议在项目启动阶段就确认清楚不然后期改造代价很大。1.2 四层验收模型从硬件到系统的完整闭环人脸识别门禁项目表面上看起来就是“刷脸开门”但真正验收时要拆成四个层面任何一个层面出问题都会影响整体交付质量。第一层是环境与安装工艺。包括设备安装高度、角度、补光条件、网络布线、供电稳定性。这个层面最容易被忽略但恰恰是现场识别率低、设备掉线的主要原因。比如人脸识别一体机的安装高度如果装得太高超过1.5米摄像头俯视角度过大识别率就会明显下降。按常规经验壁挂式人脸机的推荐安装高度是1.4米到1.5米之间摄像头中心对人脸高度。这个在验收时要实测不能只看设备能通电就完事。第二层是硬件状态。包括摄像头分辨率、红外补光灯是否正常、设备温度、内存占用、存储剩余空间等。人脸识别门禁机在持续运行时如果散热设计不好设备温度过高会导致CPU降频识别速度变慢。这个在连续运行测试中能明显看出来我见过一台设备连续跑了一上午之后识别时间从200毫秒涨到600毫秒的案例后来一查是散热片贴歪了。第三层是算法性能。核心是识别率和误识率、活体检测能力、戴口罩/戴眼镜/戴帽子场景下的表现。算法性能测试需要设计专门的测试样本集不是随便找几个员工刷脸就能得出结论的。这部分内容我会在后面的章节里详细展开。第四层是系统稳定性和业务闭环。包括鸿蒙系统的开机自启、进程守护、断网离线识别、数据缓存与补传、OTA升级、日志记录完整性等。这是鸿蒙设备验收的特色内容也是很多习惯了安卓设备的集成商容易漏掉的地方。鸿蒙系统的分布式能力和生命周期管理机制跟安卓差异不小如果应用没有适配好可能出现杀后台、升级后配置丢失、日志写不进去等问题。1.3 什么样的测试样本量才说明问题验收评测最怕的就是拍脑袋定标准。见过不少项目验收时找两个员工各刷十次脸识别成功就算通过这种测试毫无意义。要给出一个相对可信的结论测试样本量至少要达到这个水平性能基准测试至少选择30名不同年龄、性别、肤色、戴眼镜情况的人员参与。每个测试人员至少采集5张不同角度、不同光照条件下的人脸照片作为注册底库。每人至少进行20次识别尝试覆盖正常站立、微侧脸、低头抬头场景。误识测试需要用不在底库中的陌生人照片或真人至少测试200次。活体检测测试至少包含打印照片、手机屏幕照片、视频回放等常见的攻击方式每种攻击方式至少测试20次。这样算下来一轮完整评测至少需要完成数百次到上千次识别操作。这个工作量如果不提前安排人员和场地一天根本跑不完。所以我的做法是提前一天把测试人员组织好分批次到场测试现场用表格记录每次测试结果同时从设备后台导出识别日志做交叉验证。2. 评测前置条件环境、数据与工具2.1 测试场地怎么布置才有代表性很多人在项目现场随便找个位置就开始测测出来的数据波动很大今天识别率95%明天变成85%最后说不清楚是设备问题还是测试环境问题。所以评测前一定要把测试场地规范化。我的习惯是在项目现场选三个具有代表性的点位做集中评测室内光线稳定区域模拟办公楼层门禁光线变化小。室外逆光区域模拟园区大门下午太阳直射摄像头方向的场景。走廊低照度区域模拟地下车库或灯光较暗的后门。每个点位要记录光照强度、设备安装角度、补光灯是否开启、门禁周围的背景复杂度包括是否有行人来回走动、是否有大面积的玻璃反光或绿植。背景复杂会干扰人脸检测这个是算法层面的问题但可以通过调整安装位置在一定程度上缓解。实测过程中要在每个点位都放置一个照度计哪怕是用手机上的照度App也行。记录下测试时刻的光照强度后续如果识别率异常可以排查是光照变化引起的还是算法本身的问题。比如某次测试中识别率骤降一看记录时间是下午4点半太阳刚好从侧面照进走廊镜头冲光严重这时候不是设备坏了是安装角度选择有讲究。2.2 测试人像库和攻击样本怎么准备测试人像库不能直接用现场的真实员工照片因为验收前后人脸底库会变化。我建议单独准备一台测试设备或者在同一设备上划分独立的测试底库区用专门的测试人员照片建库。具体做法是注册底库采集30到50名测试人员的正脸照片光照均匀表情自然分辨率不低于设备要求的像素下限。测试人员库这30到50人需要覆盖不同年龄段20岁到60岁、是否戴眼镜、是否有刘海、男女比例尽量均衡。陌生人库另外准备20名未注册的人员作为陌生人用于误识测试。攻击样本准备彩色打印照片A4大小、手机屏幕照片原图和翻拍图、手机视频录制的人脸视频、3D打印的硅胶面具如果条件允许的话。攻击样本里最容易准备的就是A4纸打印照片和手机照片这两种也是最常见的低成本攻击方式。现在的门禁设备基本都带双目红外或者结构光活体检测对这两种攻击方式应该有很高的拦截率。比较难防的是硅胶面具和高质量的3D人脸模型这类攻击愿意花高成本准备一般不是普通门禁场景的主要威胁。验收时如果项目方有更高的安全等级要求就需要增加这些高成本攻击样本的测试。2.3 记录工具和判定基线别临时抱佛脚评测过程中的数据记录最好的方式还是传统的纸质表格加视频录制双轨进行。我在前面讲到的做法是每轮测试都让一个人专门负责记录结果同时用手机支架固定拍摄测试过程。纸质表格记录的是“第几号测试人员、第几次测试、是否通过”视频录制是为了后续复核尤其是出现异常结果时能回看当时的现场情况。设备日志的导出也很重要。鸿蒙系统的人脸门禁机一般都有本地日志功能里面会记录每次识别的时间戳、识别分数、比对耗时、是否活体通过等信息。验收时可以把这些日志导出来和现场记录做交叉比对。如果现场记录说“第3号测试人员第5次识别失败”但后台日志显示识别分数其实已经超过阈值只是活体检测环节判定为可疑那说明问题在活体策略而非人脸比对模型。判定基线方面我会在评测前先定好一套明确的阈值标准指标合格标准注册底库人数不少于30人正常场景识别通过率不低于95%陌生人误识率不超过0.1%200次测试中最多0次活体攻击拦截率不低于98%单次识别完整流程耗时不超过2秒含活体检测设备人脸比对算法耗时不超过500ms断网离线识别必须支持断网期间数据补传恢复联网后24小时内补齐这里需要说明的是不同项目对误识率和拦截率的要求不同办公楼门禁和银行金库门禁的安全等级差异非常大。上面这个表是我做普通商用办公项目时的默认标准如果项目要求更高安全等级误识率标准就要提升到万分之一甚至更低对应的阈值设置也要调整。3. 人脸识别核心性能指标怎么测才有效3.1 FRR和FAR到底怎么理解做门禁项目这么久我发现很多项目经理测人脸识别只关心“能不能识别出来”从来不区分识别率和误识率。这两个概念如果不分清楚验收很容易被厂商的数据忽悠。识别率通常对应拒识率FRR的补是“应该被放行的本人有多大概率被正确放行”。误识率FAR则是“不应该被放行的陌生人有多大概率被错误放行”。这两个指标是一对矛盾阈值调得越严格陌生人越难混进来但本人也可能被误拒阈值调松本人体验好但陌生人被放行的概率也会上升。门禁场景的安全性要求很高所以我的验收原则很简单在保证误识率为0的前提下识别通过率尽量高。如果厂商告诉我识别率99%但陌生人测试时出现了误识这个99%就是不合格的。因为门禁的核心价值不是让99%的人顺利进门而是不让任何一个不该进门的人进来。在评测时我会从设备后台调整比对阈值。一般的人脸识别门禁机比对分数阈值范围在0到1之间默认值通常在0.6到0.75之间。测试时我会从低到高调整阈值分别记录不同阈值下的FRR和FAR绘制出大致的ROC曲线趋势。虽然不像实验室那样精确但能明显看出算法底子怎么样。好的算法在阈值从0.6升到0.8的过程中FRR的增速是平缓的说明特征提取能力较强差的算法在阈值稍微提高时FRR就直线上升说明比对分数分布重叠严重。3.2 实操200次识别测试怎么跑给大家一个可以直接抄的测试流程适用于30人底库的标准评测。第一步管理员在设备上录入30名测试人员的照片每人拍一张正脸照存为注册底库。录入时注意摘掉帽子、口罩露出完整面部。眼镜是否佩戴默认保持测试人员日常佩戴状态。第二步开始正常识别测试。每名测试人员在设备前2米处站定自然走向设备在距设备0.5米到0.8米处停留等待识别。每人重复20次间隔10秒以上。这20次里要求其中5次微侧脸左右偏转约15度、5次轻微低头、5次抬头其余5次保持平视。把每次结果记录在表格中。第三步陌生人误识测试。让20名未注册的陌生人员使用同样的方式接近设备每人测试10次记录设备是否有任何一次比对成功或活体通过后的开门动作。正常要求是200次中0次误识。如果出现1次以上误识立即暂停测试调高比对阈值后重测同时这个项目要对安全等级重新做评估。第四步攻击测试。先把打印照片放在人脸识别区域前方观察设备是否有任何锁定或报警反应记录是否被拦截再用手机屏幕显示测试人员照片重复操作最后用手机播放测试人员的动态视频尝试识别。每种攻击方式重复20次。这套整个流程跑下来大概需要3到4个小时中间需要休息避免测试人员疲劳。测试建议安排在上午和下午两个时段进行光照条件不同数据更有代表性。3.3 响应时延的测量方法关于响应时延门禁项目里有两个口径容易混淆一个是纯算法比对耗时一个是完整开门流程耗时。验收时两个都要测。纯算法比对耗时是指摄像头采集到人脸图像后算法完成人脸检测、特征提取、比对、返回结果的时间。这个数值在设备后台日志里通常能看到以毫秒为单位。正常的边缘设备上这个数值一般在100到300毫秒之间。如果超过500毫秒大概率是设备算力不够或者算法做过裁剪优化在高峰时段可能会变得更慢。完整开门流程耗时是指从测试人员站到设备前开始到门锁动作结束听到“咔哒”声的时间。这个时间包括人脸检测、活体检测、比对、权限匹配、门锁继电器吸合、电锁动作的全过程。实测时用秒表就能记录我习惯测5次取平均值和最大值。商用门禁的合格线是平均值低于2秒最大值不超过3秒。体验好的设备能做到平均1到1.5秒。这里有一个小技巧如果设备支持网络开门比如通过鸿蒙系统的分布式能力联动手机App或室内机远程开门一定要单独测网络链路的时延。识别到人脸后请求通过局域网/云端转发到手机再到室内机开锁这个链路比本地开门慢很多实测局域网环境下一般多1到2秒。如果项目有对讲联动需求验收时要把这部分时延单独记录并在验收报告里注明是网络开门场景下的表现。3.4 并发高峰场景怎么模拟门禁项目验收很容易忽略并发场景。平时一人一刷很流畅但到了早上8点半大家同时到公司门口排队设备能不能连续快速识别就是一个实实在在的体验问题。模拟并发场景的方法不复杂。找10个人在设备前排队每人间隔约1米。第一个人识别完成后第二个人马上顶上中间不停顿。连续跑50次记录是否有识别等待超时、设备死机、画面卡顿、补光灯过热的异常。再用设备后台的日志记录对比看看相邻两次识别的时间间隔。正常时间间隔应该在1.5到3秒之间。高峰期还有一个容易被忽略的问题多人同时出现在画面中。有人站在设备前刷脸时后面的人探头过来人脸检测算法可能同时检测到多张脸导致识别优先级混乱。好的门禁设备会有“单人大屏跟踪”机制锁定最近的人脸或者最大的人脸进行识别。实测时可以让两个测试人员同时站在设备前一前一后故意让后边人探出头观察设备是否会出现比对错误或识别超时。并发场景下还需要关注设备的温度和功耗表现。连续高频识别会让摄像头和NPU神经网络处理单元处于高负荷状态。我用红外测温枪测过设备表面温度连续运行1小时后温度一般在35到45摄氏度之间。如果超过50摄氏度就要警惕了长期高温运行会加速元器件老化冬天可能没事夏天暴晒环境容易出问题。4. 鸿蒙系统专项评测与适配要点4.1 先确认你测的是真鸿蒙还是“安卓换壳”这个是我最近一年特别强调的一点。验收鸿蒙人脸识别门禁项目时第一件事就是确认设备的操作系统是不是真正的鸿蒙而不是安卓系统套了一个鸿蒙的桌面主题。通过两个途径确认一是查看设备系统信息。鸿蒙系统在“关于本机”里能看到操作系统版本号以及HarmonyOS或OpenHarmony的标志信息。二是查看应用安装包格式。鸿蒙原生应用是HAP格式通过鸿蒙的应用市场或本地安装方式部署如果设备上还是APK格式的应用那就不是原生鸿蒙。为什么要纠结这一点因为鸿蒙系统的资源调度、后台管理、生命周期机制和安卓差异很大。一个没有经过鸿蒙适配的安卓应用跑在鸿蒙设备上短期看不出问题但长期运行可能出现后台被杀、消息推送延迟、OTA升级后配置丢失等稳定性问题。门禁设备是7x24小时运行的稳定性和安卓时代的“能用就行”完全不是一个标准。我在一个项目里就碰到过这样的问题设备是某厂商的“鸿蒙版”门禁机但识别应用还是安卓APK格式。验收前测试时发现设备偶尔会出现应用闪退重启后恢复。后来厂商把应用重新编译成HAP格式同时对鸿蒙系统的权限管理做了适配闪退问题才彻底解决。所以原生鸿蒙适配这件事验收时还是要较真。4.2 开机自启与进程守护必须实测门禁设备有一个特点断电恢复后必须能自动进入正常待机识别状态。如果是办公电脑断个电开机后手动点一下应用还能接受但门禁设备如果每次断电都要人工去设备上点一下“打开应用”那维护成本就不可接受了。鸿蒙系统设备在验收时要实测以下场景设备通电后系统自动启动识别应用是否会自动运行并进入识别界面。应用异常退出后比如通过开发者选项强制结束进程是否会自动拉起重启。设备在无人操作状态下连续运行72小时是否有进程假死、界面无响应的情况。测试方法很简单在验收前一天晚上给设备断电第二天早上通电观察设备是否能自动恢复到正常识别状态。再做一次强制关闭识别应用的操作观察设备是否能在1分钟内自动恢复。这些测试不需要复杂工具但对设备的实际使用体验影响巨大。鸿蒙系统在进程管理上和安卓有差别应用需要正确处理系统的生命周期回调否则在后台一段时间后可能被系统清理。这也是原生适配比“安卓换壳”更可靠的原因之一原生鸿蒙应用会正确处理这些回调保证门禁这种前台服务不被系统误杀。4.3 分布式能力别沦为PPT功能鸿蒙系统的分布式软总线是一大卖点很多厂商宣传“门禁机与室内机、手机App无缝协同”。验收时要验证这些跨设备协同功能是否真的能落地而不是演示时能用、平时就掉链子。项目里最常见的分布式场景有两个。一个是门禁机呼叫室内机。访客在单元门按门铃呼叫后室内机弹出来访画面住户确认后远程开锁。验收时要测室内机与门禁机之间的实时视频画面时延、对讲声音质量、远程开锁的响应速度。局域网环境下视频画面时延一般应在500毫秒以内远程开锁响应应在2秒以内。另一个是手机App远程开门。通过鸿蒙系统的跨端流转能力把门禁机的识别状态和实时画面流转到手机App上住户不在家时也能看到访客并远程开门。这项功能对网络依赖很强验收时要分别测试局域网和4G/5G外网环境下的响应表现。外网环境下远程开门一般会有2到5秒的延迟也要在验收报告里如实记录。华为自研PC版鸿蒙系统的消息流转能力比我预想的更强但在跨品牌手机上体验有差异。如果项目方员工用的手机都是鸿蒙系统这个协同体验就很好如果员工手机品牌五花八门跨品牌体验不稳定那这个功能就要在验收时按实际场景评估不能只看厂商宣传。4.4 OTA升级与配置持久化测试门禁设备不是装完就一劳永逸的后面算法迭代、安全补丁、系统更新都走OTA升级通道。OTA升级容易出问题的点主要有两个升级后配置丢失以及升级失败导致设备变砖。验收时要做一次完整的OTA升级测试。操作步骤是先备份当前设备的全部配置人员底库、开门权限、网络参数、时间同步等。向设备推送一个测试版本的系统固件。等待升级完成并自动重启。升级后检查人员底库是否完整、网络参数是否保留、设备时间是否正确、应用版本是否更新到位。在升级过程中现场断电模拟升级到一半断电的异常场景检查设备是否能从异常中恢复并回到正常启动流程。如果一个门禁系统做了几十上百个点位OTA升级后要一台台重新录入员工人脸那是灾难性的。所以配置持久化是鸿蒙门禁设备验收的高优先级指标如果这个环节有问题项目后期维护成本会非常高。5. 集成商验收评测清单与SOP执行脚本5.1 可复制的项目验收评测清单以下这份清单是我目前在项目中实际使用的版本每一项都有明确的验收方法和合格标准。可以直接打印出来作为现场验收表使用。评测大项子项验收方法合格标准安装与硬件安装高度与角度实测摄像机中心对人脸高度1.4-1.5米安装与硬件供电稳定性连续运行72小时后检查是否掉电重启无异常掉电安装与硬件补光灯状态低照度下观察补光灯是否自动点亮正常点亮安装与硬件设备发热高负荷运行1小时后测表面温度低于50℃人脸识别正常识别通过率30人各测20次不低于95%人脸识别陌生人误识率20名陌生人各测10次0次误识人脸识别活体攻击拦截率打印照片、屏幕照片、视频攻击各20次不低于98%人脸识别比对算法耗时后台日志读取不超过500ms人脸识别完整开门流程耗时秒表实测10次取平均不超过2秒人脸识别高峰期连续识别10人排队连续50次无死机、无异常超时鸿蒙系统系统版本确认设备关于本机查看确认为HarmonyOS/OpenHarmony鸿蒙系统应用包格式查看应用安装包HAP格式为佳鸿蒙系统开机自启断电重启后观察应用状态自动恢复识别鸿蒙系统应用进程守护强制结束应用进程1分钟内自动恢复鸿蒙系统分布式呼叫门禁机呼叫室内机/手机App视频时延低于500ms鸿蒙系统远程开门响应手机App远程操作外网2-5秒内响应鸿蒙系统OTA升级配置持久化升级后查看配置和底库配置完整保留网络与运维断网离线识别断开网络后测试识别正常离线识别网络与运维数据缓存与补传断网期间产生的记录恢复网络后检查24小时内补传完整网络与运维门禁日志完整性导出日志与现场记录交叉比对日志完整无缺失5.2 现场验收执行的SOP脚本评测清单有了还需要一个明确的执行顺序不然现场很容易漏项或者做重复工作。我习惯把一天验收流程拆成三个半天上午环境与硬件检查。先检查所有点位的安装高度、角度、供电和网络情况。同时对重点点位做断电重启测试确认设备上电后能自动恢复正常。这个阶段发现问题就直接记录不急着判定因为有些问题是环境引起的调整后可以解决。下午识别性能与安全测试。这是最耗时的部分。把30名测试人员安排好按照“正常识别 → 陌生人误识 → 攻击测试”的顺序逐项跑。中间穿插响应时延的秒表记录。这个阶段建议至少安排两名助手一人负责引导测试人员站位一人负责记录数据。第二天上午鸿蒙专项与稳定性测试。做OTA升级测试、分布式联动测试、断网离线识别和数据补传测试。同时在设备上开启持续运行的稳定性记录从当天上午开始到第三天早上结束满足72小时连续运行要求。5.3 验收报告的写法建议验收报告是项目的法律依据写得严谨对双方都是保护。我的报告结构一般包括项目基本信息项目名称、验收时间、参与人员、设备型号和数量、系统版本号。需求追溯表合同里的每一条需求对应到验收方法、实际测试结果、是否满足。测试数据明细每项测试的原始记录表包括测试人员编号、测试时间、测试结果、异常记录。问题清单测试中发现的全部问题按严重程度分级标注责任方和整改期限。验收结论满足验收条件的设备清单和不满足的设备清单明确是否进入整改阶段。报告里一定要贴上关键测试过程的照片或截图比如活体攻击测试时“被拦截”的系统提示界面、OTA升级成功后的版本号截图、设备自动恢复后的识别界面。这些留痕资料在后期项目争议时有据可查。6. 现场常见问题与排查经验6.1 逆光环境下识别率断崖下跌室外门禁最典型的问题下午太阳直射摄像头方向人脸处于逆光状态画面中面部发黑识别率直接从95%掉到70%以下。排查思路先看摄像头本身的宽动态WDR是否开启。很多设备出厂设置里宽动态默认关闭或者档位不合适。现场调整参数时不要只看识别率数字要同时观察实时预览画面中的人脸是否清晰。最直接的判断标准你人站在设备前肉眼通过监视画面能看清自己的五官轮廓这个状态下识别大概率没问题。另外一个容易被忽略的点是补光灯的角度。有些设备支持外接补光灯补光灯安装在设备正上方或者侧面角度不对会导致人脸局部过曝或阴影。调整补光灯角度时让测试人员站在设备前从设备画面观察人脸亮度的均匀性以面部中央区域亮度适中、两侧无明显阴影为准。6.2 戴口罩识别策略影响正常通行体验疫情之后很多门禁设备都支持了戴口罩识别。但戴口罩识别的问题在于算法只能依赖眼部周围特征识别准确率天然比全脸识别低。实际测试中我发现同一台设备全脸识别通过率能达到98%但戴口罩识别可能掉到85%而且陌生人误识率也会上升。如果项目对安全等级要求较高一个比较稳妥的方案是默认关闭戴口罩识别需要通行时摘下口罩。如果项目方要求必须支持戴口罩识别比如医院场景验收标准就要单独设定识别通过率可以适当放宽到90%以上同时误识率必须保持0。另外口罩遮住了下半部分脸部活体检测的很多特征点比如唇部运动就失效了。这时候要依赖红外活体或者结构光活体方案。如果设备用的是普通RGB摄像头方案戴口罩状态下活体检测的可靠性会打折验收时要把整个测试过程做成视频留底。6.3 鸿蒙设备OTA升级后配置丢失这个问题的表现是升级之前一切正常升级后重启系统能起来但人脸底库空了、网络地址变成了DHCP自动获取、之前配置的联动关系全部丢失。原因是应用没有把配置数据写到系统数据分区而是写在应用沙箱缓存目录里OTA升级后应用数据被清掉了。纯安卓时代这个问题也存在但很多厂商在老方案里做过特殊处理换到鸿蒙平台后适配没做到位问题就复现了。排查方法是检查应用的数据存储目录确认配置和底库数据是写在持久化存储路径下而不是临时目录。这个需要在开发阶段确认集成商在验收时能做的就是完整测一遍升级流程。如果升级后配置丢失立即降级回旧版本恢复现场同时要求厂商修复后再安排二次升级。6.4 识别记录上报丢失门禁项目一般都有平台对接需求识别记录要实时或准实时地上报到管理平台。实际项目中经常出现的问题是设备本地能看到识别记录但平台端少记录、漏记录。排查时先区分是设备上报失败还是平台接收失败。在设备后台查看上报日志确认HTTP或MQTT请求是否成功响应码是多少。如果设备显示上报成功但平台没有数据问题大概率在平台端的接口或数据库如果设备显示上报失败就要看网络连通性、接口地址配置、数据格式是否匹配。断网场景下的缓存和补传机制也要重点测试。断开设备网络模拟10次识别恢复网络后检查这10条记录是否在24小时内补齐上报。如果设备没有补传能力需要和项目方确认是否能接受这个限制并在验收报告中明确标注。最后说几句实在话做门禁项目验收最怕的不是技术问题而是标准和预期不清。设备和系统都是产品总会有这样那样的限制关键是验收之前就把标准定清楚验收过程中每个结论都有测试数据支撑有问题就摆在桌面上谈。鸿蒙系统的人脸识别门禁项目这几年正在快速增加我能明显感觉到真正通过这套评测验收逻辑筛下来的设备现场运行的稳定性和后期维护的省心程度确实比没有经过这套流程的设备高一个档次。建议集成商同行们把这个清单当作一个起点结合自己项目的实际安全等级、环境条件和甲方要求来做裁剪把适合自己的验收标准固化到项目管理和交付规范里后面再做同类项目会轻松很多。