企业官网建设流程全解析

每年开学季前后，是智慧校园项目最集中上量的时间段。门禁、访客、食堂消费、宿舍管理，样样都赶在新生报到前要完成联调。今年特别不一样的是，好几个项目都在技术选型时明确要求“往鸿蒙方向上靠”。这里说的鸿蒙，既包括终端设备上运行的 HarmonyOS 生态，也包括设备端基于 OpenHarmony 的改造方案。人脸识别门禁和食堂刷脸，恰恰是智慧校园里最有代表性的两个场景，一个管安全，一个管效率，两者叠加在一起，几乎就是开学季智慧校园升级的标配。

这篇文章我不会去画架构图，也不打算堆一堆概念名词。我按一个集成商技术负责人的视角，把我实际在项目里踩过的坑、总结的套路、验证过的配置全部展开来写。适合正在做智慧校园项目的系统集成商、学校信息化老师、准备进入这个方向但又不知道从何下手的鸿蒙应用开发者阅读。内容会涉及方案选型、端侧人脸识别实现、鸿蒙端 App 开发、食堂刷脸的账务处理、高并发压测以及现场验收的问题速查，整体偏实战。

1. 智慧校园项目为什么绕不开鸿蒙？方案整体怎么拆

1.1 开学季的典型场景：门禁和食堂是两块硬骨头

开学季做智慧校园升级，很少有学校会一步到位搞“数字孪生”“AI 巡检”这类大而全的东西，实际预算和工期都集中在两类刚需场景上。

第一类是校门、宿舍楼、实验楼的门禁通行。新生入学、家长接送、外来访客，人员结构在开学头两周是最复杂的。传统刷卡门禁最大的问题不是刷不开，而是卡片容易忘带、丢失后被复制，以及保安根本没法判断刷卡的人是不是卡主本人。人脸识别门禁解决的是“人证合一”的问题，把人脸特征作为通行凭证，不需要额外携带任何物理介质。

第二类是食堂刷脸消费。中学和高校食堂的就餐高峰非常集中，中午 11:40 到 12:20 这四十分钟是绝对的大流量时段。以前用饭卡，学生要先找卡、再刷卡，平均一个人要 3 到 5 秒；遇到读卡器反应慢，窗口能堵成一团。刷脸的好处是“人到即扣”，整个识别加扣款过程控制在 1 秒左右，效率提升非常明显。但食堂刷脸的问题也比门禁更复杂，后面我会详细讲账务、并发和防重扣的坑。

1.2 鸿蒙体系在这类项目里的真实长处

很多集成商朋友一听到“鸿蒙”就很头痛，觉得又多了一套要学的东西。实际上从做项目角度理解，鸿蒙给智慧校园带来的增量主要在三块。

第一块是分布式设备协同。传统门禁系统的架构是“门禁机 + 管理后台”，门禁机是独立的，后台是独立的，两者之间只有配置下发和数据上报。鸿蒙生态不一样，它天然把摄像头、门禁机、闸机、管理后台、移动端 App 看成一组协同的“超级终端”。在实际落地中，最直观的体验是：学生在手机端通过 HarmonyOS App 完成人脸录入后，数据可以直接流转到门禁终端和食堂消费终端，不需要再走一遍“后台导出—U 盘拷贝—终端导入”的老流程。

第二块是开发框架的统一。以前做智慧校园，门禁终端往往是 Android 系统，食堂消费机又可能是另一个嵌入式平台，管理端还要再做一套 Windows 程序。三个端三套团队维护，升级一次要协调三方排期。鸿蒙方案下，门禁终端、消费终端如果基于 OpenHarmony，设备开发用 HDF（硬件驱动框架）对接外设；管理端和移动端用 ArkTS 写 HarmonyOS 应用。至少从软件栈角度，整个项目能做到南北向统一，维护成本明显下降。

第三块也是不能回避的，就是信息化设备的自主可控要求正在成为学校采购的硬性约束。以前集成商拿 Android 方案就能交差，现在多轮论证、招标文件、验收标准里都容易出现“是否支持国产操作系统”“是否具备鸿蒙兼容性”这一类条目。提前把鸿蒙作为项目方案的技术底座，在招投标阶段是有明显优势的。

1.3 整体架构按“端—边—云”三层来拆

我不建议把整个智慧校园项目做成一个巨大的单体系统，实操中最好按“端—边—云”三层来切。

端侧是部署在每个大门口、宿舍楼、食堂窗口的人脸识别终端和消费终端。端侧最重要的任务是“本地化识别”，人脸特征提取和比对必须在本地完成。为什么不能全靠云端？最直接的原因是网络抖动。学校网络在开学季高峰期很不稳定，如果每个学生刷脸都要先上传照片到服务器再等返回结果，高峰期等待时间会飙到 3 秒以上，而且一旦断网整个大门就瘫痪了。正确做法是端侧预置离线特征库，识别结果本地出，再把通行或消费记录异步上抛。

边缘层是每栋楼的边缘网关或者管理终端，负责汇聚这一栋楼的设备数据，做临时缓存和断网续传。

云端层是部署在学校机房或者云服务器上的管理平台，负责人员底库、人脸照片存储、授权策略、消费扣款对账、设备管理和大屏展示。云端还承担一个关键任务——把录入的人脸特征值通过加密通道同步到各端侧设备。

2. 人脸识别门禁的落地细节：算法、硬件与鸿蒙端开发

2.1 人脸识别算法选型：商用 SDK 还是开源模型

人识别算法是整个门禁系统的大脑。选型上我一般先问项目现场两个问题：摄像头是否固定、是否需要活体检测。固定点位、需要防照片视频攻击，这两个条件基本决定了要选的能力范围。

商用方案里，虹软 ArcFace、旷视 Face++、百度、海康、大华的 SDK 都是成熟选择。好处是文档齐全、集成省事，离线 SDK 可以直接跑在门禁终端的板卡上，不需要依赖公网。商用授权费用按设备数计算，开学季项目动辄几十个门禁点位加上几十个食堂窗口，授权成本还是要提前算清楚的。

开源方案里，InsightFace 的 ArcFace 系列模型在学术界和工业界的口碑都很稳，识别精度在 LFW 和 MegaFace 上长期排在前列。RetinaFace 做人脸检测，MobileFaceNet 做轻量特征提取，这类模型可以量化后部署到 RK3588、RV1126 这类边缘板卡上。不过开源不等于完全没成本，你需要自己处理训练数据清洗、模型转换、推理优化、板卡适配，前期开发工作量不少。

很多集成商用 C# OpenCvSharp 做原型验证，先拉一个本地摄像头测试识别效果，逻辑通了再迁移到正式的边缘设备，这是一个非常高效的组合。OpenCvSharp 的人脸检测用 Haar Cascade 就够了，快速验证阶段完全不需要上深度学习模型；更复杂的场景再接入 OpenCV DNN 模块加载 ONNX 模型。我在原型阶段通常就是用这种组合，半小时就能搭出一个人脸框选 Demo，跟客户演示比 PPT 好使一万倍。

再强调一点，凡是涉及商用部署的开源模型，不管用什么框架，都要先看清楚许可证。有一部分开源人脸识别模型是非商用协议，校园项目虽然不直接向学生收费，但在商业集成项目中依然属于商用行为，许可证问题必须在方案阶段就排查掉，否则后期审核很被动。

2.2 门禁硬件组成与联动逻辑

人脸识别门禁不是说买一台带摄像头的门禁一体机装上去就能用。一台完整的门禁系统由四层硬件组成：门禁一体机（含摄像头和人脸比对模块）、门禁控制器（负责开关锁信号）、锁具或闸机（电磁锁、电插锁、三辊闸、翼闸）、配套设备（出门按钮、消防联动模块、电源）。

最常见的接法是：人脸识别一体机识别通过后，通过网络向门禁控制器发送“开门指令”，控制器再驱动电磁锁断电开门。这里很多人会踩坑——人脸一体机和门禁控制器之间的协议匹配。人脸一体机一般支持韦根协议或者 RS485 协议，韦根协议最通用，几乎所有门禁控制器都支持，但韦根协议传输距离有限，超过 100 米信号衰减严重，长距离部署要改用 RS485 或者网络模式。选型时先确认现场的门禁控制器是否支持网口直连，如果只支持韦根，一体机和控制器的距离就要严格控制。

另一个坑是消防联动。学校实验室、宿舍楼、图书馆对消防要求很严，一旦发生火警，所有门禁锁必须自动断电释放，不能把逃生通道锁死。这个功能必须在配电层面完成，而不是靠软件下发指令——火警时如果服务器或者交换机挂了，软件链路就断了。正确做法是在供电回路里串接消防联动模块，消防信号一到，物理断电，门锁自动弹开。

刷卡功能在门禁系统里目前还是建议保留的。虽然主打人脸识别，但人脸识别的误识率再低也不可能做到百分之百，总会有个别人的底库照片质量差导致长期识别失败。这时候一张 RFID 卡作为兜底能解决大量事故。目前校园门禁常用的卡是 Mifare 1K 卡（频率 13.56MHz）和 CPU 卡，前者的优势是便宜、兼容设备多，后者的安全性更高、防复制能力更强。对校园场景，考虑到学生卡经常和饭卡合一张，走 CPU 卡的方案更稳一点。有些项目的门禁一体机是支持刷卡+人脸双重校验的，这种“卡 + 脸”的交叉验证模式丢卡率会再降一截，但通行速度也相应变慢，适合用在实验室、机房等高安全等级点位，校门口这种大流量点位不建议开双因子。

2.3 鸿蒙端开发：管理 App 和门禁设备怎么对接

如果管理端和学生端都要跑在鸿蒙生态上，核心开发语言是 ArkTS。很多从 Android 转过来的开发者上手 ArkTS 很快，语法上像 TypeScript 和声明式 UI 的组合，状态管理、组件化思路跟 Flutter 也有相似的地方。

项目拆包上有几个概念需要先搞清楚。HAP 是应用安装包，也就是最终装到手机或平板上的东西；HSP 是动态共享包，可以在应用运行时按需加载；HAR 是静态共享包，编译期就打进 HAP 里了。实操中，我会把“人脸录入”“刷卡记录查询”“消费明细”这类通用能力封装成 HAR，在多个 HAP 间复用；而把每个学校个性化的“开学季活动页”“临时访客登记”等功能做成 HSP，改造频繁但又不希望整个应用重新安装。

门禁终端侧的鸿蒙化，重点在 HDF 框架。HDF 的作用是统一外设驱动的开发接口。人脸识别门禁一体机除了屏幕，还有摄像头、补光灯、喇叭、RS485 串口、韦根接口，这些外设驱动都要在 OpenHarmony 系统里通过 HDF 去做适配。如果像 MCU 方案那样，核心逻辑跑在单片机里、显示屏只是简单显示，那鸿蒙系统承担的更多是“应用编排和数据展示”的角色，HDF 的工作量会小不少。但如果是完整的 OpenHarmony 系统跑在四核或者八核应用处理器上，那摄像头驱动、NPU 推理框架、显示合成，这些是真正需要投入人力的地方。

有一点必须提前说清楚：目前市面上真正标配 OpenHarmony 系统的门禁一体机并不算多，大部分厂商还在用 Android。实操层面更稳妥的路线是“华为生态设备做管理端和学生端，门禁终端先走标准方案，管理端通过标准 API 对接”。等到终端设备生态逐渐成熟，再逐步往设备端鸿蒙化过渡，而不是一上来就要求全链路鸿蒙，那会让项目实施周期变得不可控。

2.4 活体检测与识别阈值怎么调

人脸识别门禁最常见的攻击方式是用打印照片、手机屏幕照片、录制的视频来冒用身份。对付这类攻击，要做活体检测。目前常用的两条路线：静默活体和动作活体。

静默活体不需要用户做任何配合动作，通过分析图像里的纹理细节、反光、景深等信息判断是不是本人。华为、商汤等大厂的高端 SDK 都支持静默活体，体验好，但授权价格高。动作活体则要求用户对着摄像头“眨眨眼”“张张嘴”“左右转头”，通过分析动作过程中的面部形变来判断是否为真人。动作活体的成本低，通用性好，缺点是通行体验差，本来 1 秒就能过闸，动作活体至少要 3 到 5 秒。在早高峰的校门口，每个学生多站 3 秒，排队就会很严重。

我的建议是分级设置：校门口高峰时段，关闭动作活体，采用静默活体或者算法评分的方式，重点保证通行速度；实验楼、图书馆这类安全等级更高的点位，开启动作活体或者双因子认证。

识别阈值也是现场不得不调的参数。特征比对返回的相似度分数一般在 0 到 1 之间，阈值越高，误识别（把 A 识别成 B）越少，但误拒绝（明明是自己却不让进）越多。我一般建议按“千人底库规模”先设 0.65 这个中间值测一轮，如果现场测试出现陌生人通行的情况就往上升，升到 0.7 还压不住就要检查底库照片质量而不是盲目加阈值。如果误拒绝现象严重，就先降到 0.6 观察。这个调节过程必须带着不同类型的人脸（老人、小孩、戴眼镜、肤色差异大）实测，不能只看技术团队的自测数据。

3. 食堂刷脸怎么做到又稳又不出账？

3.1 食堂刷脸和门禁刷脸是两套逻辑

很多项目方有个误区，以为门禁人脸识别做得好，食堂刷脸直接复用同一套系统就行。实际上，这两个场景的差别非常大。门禁识别失败最多就是“进不去”，重试一次两次都行；食堂刷脸一旦识别错误，扣的是学生的钱，涉及到账实相符和对账流程，性质完全不同。

食堂环境本身的识别条件也比门禁差得多。门禁点位通常都在室外或者半室外，摄像头正对人员面部，光照相对可控；食堂窗口对着的往往是逆光方向，档口里的灯带、玻璃反光、热气、油烟，都会直接影响识别率。更麻烦的是人还常常是侧脸状态——学生打饭的时候眼睛在看菜品种类，不会特意把头转正对准摄像头。

所以严格来说，食堂刷脸不应该叫“刷脸支付”，更准确的说法是“刷脸核身 + 账户代扣”。人脸在这里的作用是确认“你是谁”，而不是单独作为一个支付凭证。确认身份之后，扣款还必须经过账户系统的确认，形成一条完整的支付流水，才能保证后续对账不出问题。

3.2 首次绑定、现场识别到扣款确认的完整闭环

食堂刷脸项目落地的第一个环节是“绑脸”，就是把学生的人脸特征和校园卡账户、微信支付或支付宝账户绑定起来。现在的学校一般用三类方式：一是在学校公众号或 App 里上传照片自助绑定；二是开学时在报到现场用采集设备统一录入；三是直接在食堂门口的绑定一体机上现场拍照绑定。自助上传虽然体验好，但照片质量参差不齐，自拍角度、光线、美颜滤镜都会导致后续识别率下降，所以项目中通常还是会安排至少一次线下采集作为底库数据来源。

识别扣款的标准流程是：学生站在摄像头前 → 设备捕捉人脸 → 提取特征并与本地离线底库比对 → 活体校验 → 返回学生身份 → 窗口阿姨在消费机上输入或选择金额 → 学生点确认或由系统按菜品自动计算金额 → 扣款成功 → 语音提示“扣款成功” → 流水异步上抛到云端。

为什么要在识别出身份之后再加一个“确认扣款”的步骤？一是给学生一个反应时间，防止人在聊天或发愣时被误扣款；二是给食堂操作员一个确认机会，防止菜没打上但钱已经扣掉的情况。如果是自助取餐的称重模式，系统还要加上“取餐重量 × 单价 = 金额”的计算逻辑，扣款前在屏幕上展示金额，由学生点击确认。

支付口令这个设计很多项目容易忽略。人脸绑定支付账户后，部分第三方支付渠道要求高风险场景下输入支付口令，但这会大大拖慢食堂高峰期的通行速度。实操中我更推荐“支付口令可配置”——小额免密，超过一定金额（比如单笔 50 元以上）才要求输入确认。这样既保证安全又不影响日常就餐效率。

3.3 高峰期的并发处理：防重、防漏、防幽灵扣款

食堂中午高峰期的并发量是智慧校园系统里最考验技术的地方。一个 3000 人的中学，中午有效就餐时间按 40 分钟计算，平均每秒要处理 1.25 笔；但实际峰值往往集中在 5 分钟以内，高峰 QPS 能到 10 到 20 笔/秒。如果还要算上学校门口闸机的人脸通行并发，入口网关要承担的压力会更大。

很多人对“并发”有一个错误的直觉，以为是硬件性能不够。其实食堂刷脸的瓶颈很少在摄像头端，而是在账户扣款服务和数据库写库环节。扣款成功了要写流水，流水写库要锁表，锁表时间一长数据库连接池立马被打满，表现为“刷脸成功但一直没有语音提示”。这个问题的根源不是单台服务器能力弱，而是扣款链路里的数据库操作没有做好拆分。

我惯用的方案是“异步流水 + 本地队列 + 防重幂等”。

首先是不能在扣款请求里同步写数据库。端侧识别成功后，把扣款消息丢进 MQ（消息队列），由消费服务异步写库。端侧只关心消息有没有发出去，不关心数据库有没有写成功，这样响应时间能控制在百毫秒级。

其次是端侧本地要维护一个持久化队列。万一 MQ 服务或者网络出现瞬时故障，流水先存在本地 SQLite 或者文件里，等网络恢复后再批量上抛。这个队列必须支持重启不丢数据，否则中午断个电，几十笔消费流水就找不回来了。

再一个是幂等防重。最让学生反感的场景是：明明只刷了一次脸，扣了两笔钱。原因往往是端侧识别成功后网络超时，客户端重试，或者用户手滑多点了一次确认。解决办法是每笔扣款请求都带一个全局唯一请求号（可以用学生 ID + 时间戳 + 随机数组合），服务端收到重复请求号时直接返回上一次的处理结果，不再二次扣款。

高频峰值下，还有一个隐藏的坑是“幽灵识别”。管理平台假死重启后，所有端侧设备同时重连，瞬间把服务器的设备接入接口打满。解决方案是把设备重连设计成指数退避，第一次重连等待 5 秒，第二次 10 秒，第三次 20 秒，依次递增，避免所有设备一窝蜂地重建连接。

3.4 断网降级：没有网络的食堂不能停摆

学校网络环境比大家想象中脆弱。施工挖断光缆、交换机电源故障、运营商出口拥堵，任何一种情况都会导致校园网不可用。如果食堂刷脸系统完全依赖云端，断网就意味着食堂无法营业，这在开学期间是绝对不能接受的。

所以食堂刷脸系统必须有强有力的断网降级策略。

第一种方式是“离线白名单 + 离线特征库”。人脸底库在部署时就被下发到每一台消费终端，终端本地就能完成“识别身份”的动作。断网时，消费机切换到离线扣款模式，流水暂存在本地。等到网络恢复，再把所有离线流水批量上传，由云端统一对账。这种模式下，断网影响的只是“云端数据实时性”，不影响现场消费。

第二种方式是“降级到刷卡或者扫码”。保留刷卡通道的意义在这里就体现了。断网时如果人脸识别也局部失效，刷卡能作为应急替补。扫码则依赖手机端的离线码，这个需要在 App 端预先缓存二维码。

要注意的是，离线流水上传之后存在对账冲突的可能。学生刷脸消费时余额是足够的，但网络恢复后，云端还有其他渠道的消费流水也进来了，可能同一时间点在云端扣款时余额不足。这种情况处理时，我的逻辑是“先到先得，按时间顺序回放流水”，而不是按上传顺序扣款。否则会出现一个学生在食堂刷了一顿饭，但云端因为他后来在超市刷卡买了东西，就把他食堂这单判成余额不足的情况，造成客诉。

4. 施工打样、并发压测与开学季验收问题速查

4.1 开学季的时间规划：暑期施工和照片采集必须提前

智慧校园项目的工期永远卡在开学日上，晚一天交付就是事故。做这个方向的集成商必须有“开学倒排期”意识。

我的项目排期一般是这样的：

• 暑期的前两周：方案对接、设备选型、门禁点位勘察、食堂档口施工条件确认。
• 七月中旬：第一台设备进场打样，搭临时环境给学校测试识别效果，让分管领导直观感受。
• 七月下旬到八月中旬：批量施工安装，完成所有点位的人脸底库采集。这里要特别提醒，教职工和学生的照片采集一定要提前，不要等开学报到当天才在门口架设备现拍。开学当天现场排队拍照 + 绑定校园卡 + 激活，经验上至少会让每个新生的处理时间多出 3 到 5 分钟，报到峰值根本处理不过来。
• 八月中下旬：联调阶段，打通门禁、食堂消费、管理后台、学生 App 四条链路。
• 开学前一周：压力测试和问题整改，重点做食堂高峰并发测试、断网演练、消防联动测试。

4.2 现场高频问题速查

我在多个项目里反复遇到过的现场问题，整理成一张速查表，新项目照着排查基本能覆盖 80% 的坑。

4.3 并发压测怎么做才不是在走过场

压测是开学季验收前必做的一环，但很多人扛着 JMeter 只会打“登录接口”，这就走偏了。人脸识别系统的压测重点不在于模拟多少次 HTTP 请求，而在于模拟“多台终端同时上抛识别记录 + 扣款流水”对服务端和数据库造成的影响。

我的做法是先在 JMeter 里构造一个模拟人脸识别终端上抛流水的脚本。线程组设置成 50 个并发线程，每台终端每秒上抛 1 到 2 条流水，持续压 10 分钟，观察服务端的 TPS、响应时间、数据库连接池使用率、MQ 消费积压数。如果发现 MQ 积压量持续上升，说明消费服务处理能力不够，需要扩容消费者数量或者优化 SQL 语句。

压测还要关注一个很多人忽略的指标：端侧离线队列的积压恢复时间。断网演练结束后恢复网络，几十台终端积压的流水同时上传，服务端能不能在可接受的时间内全部消化并且不发生重复扣款，这才是真正检验系统健壮性的时刻。

4.4 验收测试清单

开学前一周的内部验收，我建议按这个清单走一遍，比让领导口头说“测试通过了”靠谱得多。

• 识别率抽测：分别在室内正常光、逆光、暗光条件下，各测试 20 人，要求识别成功率不低于 98%。
• 活体检测对抗测试：打印 5 张不同人物的照片、准备 3 段手机录制视频，逐一在设备上尝试，要求全部拒绝。
• 通行响应时间：从人脸正视摄像头到门锁动作，记录平均耗时，要求小于 1.5 秒。
• 断电恢复测试：人为关闭门禁终端电源再恢复，确认设备自动重连平台、离线流水完整上传，无丢失。
• 食堂扣款对账：打印 100 笔测试流水，对照云端流水明细，确认无重复扣款、无漏扣错扣。
• 断网演练：切断食堂网络 30 分钟，确认消费端离线扣款可用，恢复网络后 10 分钟内完成补传。
• 消防联动测试：触发消防报警信号，确认所有门禁锁在 5 秒内自动释放。

5. 鸿蒙生态接入的几个细节：从 HAP 到设备协同

5.1 管理端、学生端、设备端三段怎么切

鸿蒙在智慧校园项目里的接入，不是简单的“做两个 App”就结束了，要站在“移动端—管理端—设备端”三段来看。

移动端是学生和家长使用最多的地方，核心功能包括：人脸照片采集/更新、通行记录查询、消费明细查询、余额充值、请假/访客申请。移动端基于 ArkTS 开发，可以用 HarmonyOS 的分布式能力做一次“从手机到大屏”的流转演示——比如食堂大妈在消费机上查看某个学生的账户信息时，可以直接调用管理端平板的屏幕，不需要再单独开发一套大屏界面。这种演示在实际投标答辩里非常加分。

管理端运行在学校的机房服务器上，处理底库管理、设备管理、授权管理、消费对账。管理端接口需要足够开放，方便和学校已有的教务系统、一卡通系统、宿管系统对接。最容易忽略的是“删除”这个能力：学生转学、教职工离职后，其人脸底库信息必须在规定时限内删除，对应的通行权限要同步回收。管理端要支持按部门、按年级进行批量授权变更，最好还要有操作日志审计。

设备端目前是生态最不成熟的一段。已经在跑的方案里，大体分两类：一类是传统 Linux / Android 设备，通过标准 API 上报数据到鸿蒙管理端，这是目前最快的落地路径；另一类是真正基于 OpenHarmony 的设备，需要投入 HDF 驱动开发和系统裁剪工作。没有极其特殊的原因，我不建议集成商在工期紧张时采用“纯血鸿蒙”的设备端方案，先走接口对接，逐步替换，是风险最低的做法。

5.2 关于 HAP / HSP / HAR 的实操建议

鸿蒙应用打包要理解三种包：HAP 可执行安装包，HSP 动态共享包，HAR 静态共享包。很多项目遇到的问题不是“不会写 ArkTS 代码”，而是“包拆得不合理，导致每次改一行代码都要重新发版”。

我的建议是：所有被多个模块引用的工具类、网络库、数据库表结构，放 HAR 里，编译期打进去，稳定可靠；所有可能按需加载的功能模块，比如“临时访客登记”“迎新活动报名”这类低频场景，放 HSP 里，运行时按需加载，减小首装体积。人脸底库采集这种核心能力，建议直接放在 HAR 里，因为它在 App 启动后马上就会被调用，动态加载反而增加出问题的概率。

设备端如果是基于 OpenHarmony 系统，应用形态通常也是 HAP。这里的 HAP 和手机上的 HAP 差异很大，设备端需要做系统裁剪。门禁一体机硬件资源有限，不需要完整跑一套带桌面的鸿蒙系统，通常只保留系统服务、HDF 外设驱动、人脸推理服务、显示合成这几个最小集。

5.3 从鸿蒙生态到“门禁联动”的想象空间

最后说一个我觉得在后续项目里会被越来越多人尝试的方向：鸿蒙设备的“找人、组网、流转”能力可以打破传统门禁按点位配置的思维定式。

传统门禁是“点位绑定”，每个闸机对应一个固定门禁控制器，人员到了哪个点位才能刷哪个点位。鸿蒙生态更擅长“多设备协同找人”。比如老师来访客接待室，访客在手机端录入临时通行权限，到访时间范围、允许进入的楼栋楼层全部配置好。访客到达宿舍楼时，宿舍楼门禁机通过鸿蒙的分布式能力，先和云端权限中心完成临时授权的动态校验，再和访客手机端做一次近场拉活确认。整个流程无缝且不需要访客提前装 App，体验比现在的二维码访客方案好很多。

当然这个方向还处在设备生态完善的过程中，但作为方案储备和技术展示，在二期和远期规划里我会建议合作学校重点关注。

6. 最后再分享一点经验

人脸识别这个方向做了几年，最深刻的体会是：识别率做到 99.9% 很容易，但现场体验做到 99% 很难。难在不是算法不行，而是底库照片质量、现场光线、师生预期管理这些“非技术”环节决定了一个项目做得好不好。

我踩过的最大一个坑，就是第一年做中学食堂项目时，没有提前采集学生底库照片，结果开学前三天才开始集中录入，几千个学生的照片质量参差不齐。一个学生家长为了省事，拍了张半张脸都在阴影里的照片，导致那个学生开学第一周每天都刷脸失败，家长投诉电话一直打到了校长办公室。从那以后，任何项目我都坚持“底库采集必须在开学前完成，并且抽检照片质量，不合格的一律重新采集”。

此外，食堂刷脸这类涉及资金扣款的系统，我强烈建议在部署完成后安排一个“试运行周”，不直接扣真钱，先用虚拟账户模拟扣款，让全校师生提前熟悉流程，发现的问题在试运行阶段处理。试运行期间的流水要和正式运行时严格隔离，避免混在一起对账困难。

智慧校园升级是个慢活，开学季只是起点，后续还有大量的数据维护、权限调整、设备巡检工作。把这些基础打扎实，比任何新技术新噱头都重要。