搬书小二前阵子接手了一台10.1寸的安卓刷脸终端，需求是在设备上完成人脸识别门禁，但团队里没有Android原生开发人力，UI和逻辑全是Web技术栈。最后落地的方式就是在物联网浏览器（IoTBrowser）里用JavaScript把整条人脸识别链路跑通：摄像头采集、画面预览、人脸检测、特征提取、底库比对、闸机联动，全部在这个Web页面里完成。这篇文章就是这次实战的完整复盘，包括方案取舍、核心代码、性能调优思路和一批实打实的坑。想用纯前端技术在边缘设备上做刷脸功能的朋友，可以参考这条路线。
1. 为什么把刷脸逻辑放进浏览器：选型考量和能力边界
1.1 浏览器刷脸的底层依赖：摄像头、GPU与本地推理
先回答一个很多人会问的问题：物联网浏览器凭什么能做人脸识别？传统印象里浏览器是个“显示壳子”，但IoTBrowser这类定制浏览器和普通浏览器的本质区别在于，它把设备的硬件能力通过原生桥接注入了Web层。摄像头取流、GPIO输出、串口读写这些能力，页面里的JS调用一段桥接API就能拿到。用人脸识别真正依赖的三样东西——摄像头帧数据、GPU矩阵运算能力、本地推理运行时——在IoTBrowser里都有对应的JS入口。
摄像头对应 navigator.mediaDevices.getUserMedia，这是W3C标准API，Chromium内核的IoTBrowser普遍支持；GPU对应WebGL，TensorFlow.js等推理库依赖它做并行矩阵运算；本地推理则通过WebAssembly和WebGL的组合实现，TinyFaceDetector、FaceRecognitionNet这类模型可以在浏览器离线跑。这三样凑齐了，人脸识别就有戏。
需要先确认你手上的IoTBrowser是不是Chromium内核。目前市面上面向商业交互终端、智能门禁、智慧屏的IoTBrowser，绝大多数是基于Chromium二次开发的，支持ES6、WebGL和WebRTC。如果还停留在老式WebView，那后面讲的方案基本跑不动。
1.2 两条技术路线：本地推理与端云协同
有了浏览器这个环境，人脸识别在架构上就分出了两条路：本地推理和端云协同。
本地推理是指模型文件直接部署在设备上，检测和特征提取全部在浏览器内用JS完成。实时性最好，不依赖网络，人脸特征不出设备，隐私合规上压力小。代价是设备的CPU和GPU要扛得住推理负载，对低端设备不友好。
端云协同则是由浏览器采集摄像头画面，把帧上传到服务端的人脸识别服务，识别完成后回传结果。IoTBrowser只负责“看”，不负责“想”。好处是设备端算力要求低、模型更新灵活，坏处是延迟受网络影响大，而且人脸数据要过网，隐私和数据合规就得费心思处理。
实际项目里还有第三种折中：前端做检测（框出人脸位置），后端做比对（验证身份）。因为检测模型通常比识别模型轻量得多，前端用TinyFaceDetector找脸成本很低，后端只处理裁剪后的人脸小图，云侧压力也小。
我这次的项目由于门禁场景要求断网可用，而且设备主板带一颗不错的GPU，最终选了纯本地推理方案。
1.3 什么场景适合IoTBrowser+JS，什么场景建议换原生
聊点掏心窝的话。IoTBrowser+JS这套组合是有适用边界的，不能什么项目都往上套。
适合的场景有：交互式刷脸终端（门禁机、访客机）、需要频繁改UI的智能设备、家电面板、物流柜、充电桩这类“业务逻辑在云端、终端做人机交互”的产品。这些产品UI迭代速度快，用Web开发改版成本低，OTA升级只推HTML/CSS/JS文件就行，不用走固件包升级。人脸识别在这里是“功能之一”，不是全部。
不适合的场景要认清：高安全级别的支付级刷脸（金融合规要求极高，浏览器环境很难过检测）、超低端硬件（主控是单核Cortex-A53级别、没有GPU的板子，JS推理大概率卡成幻灯片）、以及需要极低功耗的电池设备。这些场景老老实实用C/C++或者厂商SDK写原生逻辑，别拿浏览器硬扛。
判断标准很简单：看你的设备能不能稳定跑起WebGL，以及有没有至少1GB可用内存给浏览器进程。达不到这两个条件，后面所有优化都是空中楼阁。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 打通摄像头的第一公里：设备调试与画面采集
2.1 IoTBrowser如何把硬件能力暴露给JS
拿到开发板的第一件事不是写人脸识别，而是先确认摄像头能不能在浏览器里正常出画面。IoTBrowser的硬件能力一般通过两种方式暴露：一是标准的WebRTC接口，直接支持getUserMedia；二是厂商自定义的桥接对象，常见的是在window下面注入一个IoTBridge或hardware对象，里面有开灯、继电器控制、读取串口这类私有API。
人脸识别主要用的是前者。如果navigator.mediaDevices在设备上返回undefined，大概率是IoTBrowser的WebRTC模块被裁剪掉了，这时候只能联系厂商要带WebRTC的版本，或者走厂商自定义的视频预览接口。我碰到过一台设备，标准接口拿不到视频流，但厂商暴露了一个startPreview(videoEl, options)的桥接API，把YUV数据直接画到指定元素上，这条路也能走通。
2.2 摄像头采集的JS骨架
假设IoTBrowser支持标准接口，采集代码比想象中简单，但有几个参数必须显式设置：
javascript复制async function initCamera(videoElement, width = 1280, height = 720) {
// Android设备上preferredCamera能避免每次刷新都挑错镜头
const cameras = await navigator.mediaDevices.enumerateDevices();
const faceCamera = cameras.find(d => d.kind === 'videoinput' && d.label.includes('front'));
const stream = await navigator.mediaDevices.getUserMedia({
video: {
deviceId: faceCamera ? { exact: faceCamera.deviceId } : undefined,
width: { ideal: width },
height: { ideal: height },
frameRate: { ideal: 15, max: 20 },
facingMode: 'user'
},
audio: f