WebHID实战：浏览器直连HID外设的完整指南与踩坑记录

1. 从浏览器调起硬件外设：一次全新的实践起点

先聊点实际的。过去浏览器要跟硬件打交道，路径基本是固定的：要么走 WebUSB，要么走 Web Serial，再要么绕一圈让用户本地装个 Agent 中转。WebHID 的出现，把这些路径从“绕路”变成了“直连”。它让浏览器直接与 HID（人机交互设备）通信，不需要驱动、不需要额外软件、不需要用户单独安装什么，只需要用户授权一次，页面就能直接和设备对话。

我最初接触 WebHID 是做一个内部工具项目，需要让网页直接读取一把自定义 HID 键盘的原始输入事件——不是键盘正常打字，而是读取它上报的隐藏媒体键值和扩展数据。按传统思路就得写桌面端脚本或者配一个常驻服务。后来换成 WebHID 方案，开发量直接少了一个数量级。从那之后我就开始持续关注这项技术，也在这篇文章里把完整的思路与实践过程整理出来。

WebHID 的核心能力可以归结为一句话：浏览器直接访问 HID 设备，完成数据收发。HID 设备是什么？就是电脑上几乎所有输入外设——键盘、鼠标、游戏手柄、扫码枪、RFID 读卡器、工业控制面板、医疗设备、定制按键矩阵……它们都走 HID 协议。WebHID 让这一类外设第一次在 Web 平台上拥有了跨平台的直接通信能力。

这篇文章适合几类人看：

• 前端工程师，想了解浏览器新能力边界，以及如何接外设需求；
• 产品经理或独立开发者，需要在不写客户端的情况下搞定硬件联动；
• 测试/运维人员，需要快速做硬件设备的网页诊断、校验、刷配置工具；
• 以及所有对“网页能控制硬件”这件事有好奇心的人。

文章中我会拆开三层来讲：底层协议与浏览器 API 的关系、实际开发流程中的关键步骤和代码形态、以及我在真实项目中踩过的坑和排查经验。尽量讲透，也尽量让基础薄弱的朋友能跟着落地出第一个 Demo。

2. 为什么选 WebHID：技术背景与方案选型的权衡

2.1 HID 协议和浏览器的交集点

在 WebHID 出现之前，前端想要和外设交互，并非完全没有办法，但每个方案都有自己的短板。

• WebUSB：覆盖面广，但它走的是 USB 原生协议，设备必须实现 USB 规范中的传输端点。很多成熟 HID 设备只暴露 HID 接口，并不按照 USB 通用端点设计，所以 WebUSB 拿它们没办法，或者需要额外的规避手段。
• Web Serial：串口通信很强大，但要求设备具备串口能力，而且使用前需要用户手动指定端口、设置波特率，体验上略重。除非是工厂调试或特殊工业硬件，否则拿来当通用外设方案并不顺手。
• 本地代理 + WebSocket：当然可行，但需要用户安装客户端，跨平台维护成本也高，与“网页即产品”的初衷背道而驰。

WebHID 瞄准的是 HID 设备这个最普及的外设类别。它在浏览器层面实现了 HID 报告的读取和发送，用最简单的方式覆盖掉绝大多数输入设备。对使用者来说，打开一个网页点两下授权，设备就接上了。这是很明显的体验升级。

2.2 为什么浏览器能做这件事

浏览器本质上是一个安全沙箱。它不合适也不应该直接给网页任意硬件访问权。所以 WebHID 的设计里加了三道关卡：

1. HTTPS 强制：WebHID API 只在安全上下文中可用，本地开发时 localhost 算例外。保证了传输层环境可控。
2. 用户授权动作：调用navigator.hid.requestDevice()必须是由用户手势触发（点击、按键等），浏览器弹出设备选择器，用户明确选择后才能获得访问权。
3. 设备颗粒度：授权是绑定到特定设备的 VID（厂商 ID）、PID（产品 ID）和 usage 页面/用法的组合。拿到的设备集合非常具体，不是一次授权全部设备。

这套设计让我想起操作系统的权限模型——用户不感知不授权，应用就触碰不到硬件。它是浏览器的“应用层权限”，但与系统级权限形成了良好互补，既不影响桌面应用的既有模式，又给 Web 赋予了外设控制能力。

2.3 选 WebHID 而不是等 WebUSB

如果团队不是一个新项目从零起，很可能会遇到已经在用 WebUSB 的老代码。我的建议是：如果目标设备是 HID 类设备，且主要交互是“获取输入报告/发送输出报告”，果断选 WebHID。理由有三：

• HID 设备的抽象层级更匹配：协议天然包含报告描述符，能直接区分输入、输出、Feature 报告，而 WebUSB 里这些都要自己拼端点逻辑。
• 交互更统一：免驱动能力在 HID 设备上最完整。Windows 也好、macOS 也好，系统对 HID 的识别是天然的，浏览器只是借助系统能力。
• 开发与测试环境更轻：WebHID 的 Device 对象直接暴露 collection 信息，方便页面做动态渲染；不像 WebUSB 那样需要层层处理和缓冲。

当然，如果设备本身就不是 HID 类，比如海量存储、摄像头、自定义的裸 USB 芯片，那就别硬套 HID，WebUSB 才是合适的。技术选型最怕“一竿子打翻一船人”，按需选取才是正道。

提示：判断标准很简单——设备插入后，系统设备管理器里是否显示为“HID 兼容设备”，或者设备附带的说明书里有没有写“遵循 HID 协议”。如果有，WebHID 基本就是最佳选择。

3. WebHID 核心细节梳理：从设备模型到数据通道

3.1 HID 报告格式：那棵必须理解的树

HID 协议的数据模型，核心其实就一个概念：报告（Report）。设备通过报告把输入数据传输给主机，主机也通过报告向设备发送指令。

要理解 WebHID 的流程，先得理解报告描述符（Report Descriptor）。它定义了这个设备有哪些 Report，每个 Report 包含哪些字段，分别是多少位，取值范围是多少。浏览器会把这份描述符解析成层级结构，暴露给 JavaScript 使用。

以下是一个简化版游戏手柄报告描述符的样式（十六进制表示）：

0x05, 0x01, // Usage Page (Generic Desktop) 0x09, 0x05, // Usage (Game Pad) 0xA1, 0x01, // Collection (Application) 0x05, 0x09, // Usage Page (Button) 0x19, 0x01, // Usage Minimum (1) 0x29, 0x08, // Usage Maximum (8) 0x15, 0x00, // Logical Minimum (0) 0x25, 0x01, // Logical Maximum (1) 0x75, 0x01, // Report Size (1) 0x95, 0x08, // Report Count (8) 0x81, 0x02, // Input (Data, Variable, Absolute) 0x05, 0x01, // Usage Page (Generic Desktop) 0x09, 0x01, // Usage (Pointer) 0xA1, 0x00, // Collection (Physical) 0x09, 0x30, // Usage (X) 0x09, 0x31, // Usage (Y) 0x16, 0x00, 0x00, // Logical Minimum (0) 0x26, 0xFF, 0x03, // Logical Maximum (1023) 0x75, 0x0A, // Report Size (10) 0x95, 0x02, // Report Count (2) 0x81, 0x02, // Input (Data, Variable, Absolute) 0xC0, // End Collection 0xC0 // End Collection

这段描述符定义了 8 个按键（每个 1 位）以及 X、Y 两个 10 位的模拟轴。WebHID 拿到后，会在 Device 对象的collections属性里暴露这些结构。

3.2 设备接入前的准备：鉴权、枚举与过滤

WebHID 提供两组关键接口：hid.getDevices()用于获取已经授权过的设备列表，hid.requestDevice()用于请求新设备授权。

// 获取已授权设备列表 const grantedDevices = await navigator.hid.getDevices(); console.log('已授权设备:', grantedDevices); // 请求用户授权，只显示符合过滤条件的设备 let device; try { device = await navigator.hid.requestDevice({ filters: [ { vendorId: 0x1234, // 厂商 ID productId: 0x5678, // 产品 ID usagePage: 0x0C, // 使用页面（Consumer） }, ], }); } catch (err) { // 用户取消授权 console.log('用户取消了设备选择'); return; }

filters参数是可选的。如果传入厂商 ID 和产品 ID，那么浏览器弹出的选择列表里只会出现匹配的设备；如果不传，那就列出所有当前系统里可访问的 HID 设备。这种方式适合做通用型工具，但用户选择时可能眼花缭乱。对于面向固定硬件的应用，一定要加过滤器，减少误操作。

3.3 打开设备：从选到了到能通信

拿到 Device 对象后，不能急着收发数据，第一步是调用open()方法。

if (!device.opened) { await device.open(); } console.log('设备已打开:', device.productName);

open()是异步的，会开始与系统底层交互。打开之后，Device 对象会监听inputreport事件，只要设备主动上报数据，事件就会触发。

这里有一个重要细节：如果设备已经被系统“占用”（比如键盘正在正常打字输入，系统输入服务捕获了它），浏览器打开时会失败。WebHID 在桌面端的策略是，某些设备因为系统级独占，网页是拿不到它们的输入流的。所以实践中通常会选那些系统没有默认消费的设备，比如自定义按键板、扫码枪、RFID 读卡器、部分手柄。

3.4 收发数据：inputreport、sendReport、sendFeatureReport

WebHID 的数据通道分三类：

• Input Report：设备主动向主机上报的数据（按键状态、传感器数值等）
• Output Report：主机向设备发送的数据（开灯、震动、设置参数等）
• Feature Report：双向配置型数据，用于读取/写入设备的配置信息

接收数据靠监听事件：

device.addEventListener('inputreport', (event) => { const { data, device, reportId } = event; // data 是 DataView 对象，按字节解析 const bytes = new Uint8Array(data.buffer); console.log(`收到报告 ID=${reportId}, 数据:`, bytes); });

发送数据使用sendReport或sendFeatureReport：

// 发送 Output Report，reportId 为 0 表示不使用编号报告 await device.sendReport(0, Uint8Array.from([0xFF, 0x01, 0x02])); // 读取 Feature Report const featureData = await device.receiveFeatureReport(1); console.log('Feature 数据:', new Uint8Array(featureData.buffer));

需要特别注意字节序和位域抽取。HID 协议中的模拟轴、开关组可能不是按整字节对齐的，需要自己做移位和掩码运算。我在项目中封装了一套小工具来拆解位域，省了很多事：

function extractBits(data, byteOffset, bitOffset, bitLength) { let value = 0; for (let i = 0; i < bitLength; i++) { const byteIndex = byteOffset + Math.floor((bitOffset + i) / 8); const bitIndex = (bitOffset + i) % 8; const bit = (data[byteIndex] >> (7 - bitIndex)) & 0x01; value = (value << 1) | bit; } return value; }

这种函数虽然小，但特别好用。做设备的协议解析时，你会反复用到它。

3.5 设备断开与重连：体验必须处理的边界

外设最不可避免的事情就是“突然断开”。WebHID 通过disconnect事件感知掉线，开发时需要处理好状态机：

navigator.hid.addEventListener('disconnect', (event) => { const disconnectedDevice = event.device; console.warn('设备断开:', disconnectedDevice.productName); // 更新 UI 状态，停止轮询或等待 });

同时也要处理浏览器页面刷新后的恢复。刷新页面之后，requestDevice()不会再次弹出授权窗口，因为授权是持久化的（相对于源 origin）。此时应调用getDevices()自动拿回设备列表，并重新打开。

const devices = await navigator.hid.getDevices(); if (devices.length > 0 && !devices[0].opened) { await devices[0].open(); }

这个恢复流程如果做得好，用户几乎感知不到“外设连接”的状态变化，体验会更自然。

4. 实操：从零构建一个浏览器端的 HID 通信 Demo

4.1 需求定义与场景设定

为了让实践过程更具体，我自己拟了一个模拟项目 X：做一个浏览器端的 RFID 读卡器测试面板。硬件是某公司生产的 USB HID 读卡器，它会把卡号当作键盘事件逐字符“打出来”，或者以 Input Report 形式把卡号一次性发送上来。我在这个示例里设定它启动后以固定报告格式上报 8 字节卡号。

目标很简单：浏览器打开页面，授权设备，读卡器一刷就显示卡号，并附带历史记录。

4.2 环境准备

搭建这个 Demo 不需要任何框架。简单起一个静态服务器即可。

mkdir webhid-rfid-demo cd webhid-rfid-demo # 任意静态文件服务均可，比如 Python 自带模块 python3 -m http.server 8080

页面文件结构：

webhid-rfid-demo/ ├── index.html ├── app.js └── style.css

必须通过localhost或 HTTPS 访问。直接用file://打开是没有权限调用 WebHID 的。

4.3 页面设计与状态管理

我的核心页面设计分成三块区域：

1. 顶部操作区：授权按钮、设备连接状态显示
2. 数据展示区：当前卡号、解析后的时间戳、解码结果
3. 历史记录区：滚动列表展示最近 20 条记录

对应 HTML 大体如下：

<main> <section class="controls"> <button id="connectBtn">授权并连接读卡器</button> <span id="deviceStatus">未连接</span> </section> <section class="data"> <h2>当前卡号</h2> <p id="cardNumber" class="card-number">--</p> </section> <section class="history"> <h2>刷卡记录</h2> <ul id="historyList"></ul> </section> </main>

4.4 完整实现流程

4.4.1 授权与打开

在app.js里，我把授权过程封装成了一个函数，方便重复调用：

const connectBtn = document.getElementById('connectBtn'); const deviceStatus = document.getElementById('deviceStatus'); let device = null; connectBtn.addEventListener('click', async () => { try { const devices = await navigator.hid.requestDevice({ filters: [ { vendorId: 0xABCD, productId: 0x1234 }, ], }); if (devices.length === 0) return; device = devices[0]; await device.open(); deviceStatus.textContent = `已连接: ${device.productName}`; device.addEventListener('inputreport', onInputReport); } catch (e) { console.error('授权失败:', e); } });

这里的vendorId和productId是模拟值，实际开发中请换成自己设备的真实数值。如果你不确定设备的 VID/PID，可以先不传过滤器，设备选择器会把所有 HID 设备列出来。

4.4.2 解析输入报告

假设读卡器以报告 ID 1 发送 8 字节的卡号数据（BCD 码编码），解析代码如下：

function onInputReport(event) { const bytes = new Uint8Array(event.data.buffer); if (event.reportId !== 1 || bytes.length < 8) return; const cardNumber = parseBCD(bytes); renderCard(cardNumber); } function parseBCD(data) { let result = ''; for (let i = 0; i < data.length; i++) { const high = (data[i] >> 4) & 0x0F; const low = data[i] & 0x0F; if (high >= 0 && high <= 9) result += high.toString(); if (low >= 0 && low <= 9) result += low.toString(); } return result; }

BCG 解码是读卡器常用的编码方式之一。每一位十六进制数代表两个十进制数位，所以一个 8 字节包能表示 16 位卡号。如果你的设备发送的是 ASCII 字符串，那么直接String.fromCharCode(...bytes)即可，更简单。

4.4.3 渲染结果与历史记录

function renderCard(cardNumber) { const cardEl = document.getElementById('cardNumber'); cardEl.textContent = cardNumber; const listEl = document.getElementById('historyList'); const li = document.createElement('li'); li.textContent = `${new Date().toLocaleTimeString()} - ${cardNumber}`; listEl.insertBefore(li, listEl.firstChild); while (listEl.children.length > 20) { listEl.removeChild(listEl.lastChild); } }

这段代码很直接，核心就是把 inputreport 事件变成用户可读的展示。

4.4.4 刷新后恢复连接

为了提升体验，我在页面加载时尝试恢复已授权的设备：

async function restoreConnection() { const devices = await navigator.hid.getDevices(); if (devices.length > 0) { device = devices[0]; await device.open(); deviceStatus.textContent = `已恢复连接: ${device.productName}`; device.addEventListener('inputreport', onInputReport); } } window.addEventListener('DOMContentLoaded', restoreConnection);

加上这段之后，我每次刷新页面都不需要重新点授权按钮，设备还是那个设备，连接直接恢复了。这个细节很提升工具类页面的实用性。

4.5 参数选择的现场记录

这个 Demo 里的关键参数有两个：vendorId和reportId。

• vendorId是设备厂商 ID，由 USB 标准组织分配。某公司的读卡器通常有自己的固定 VID，你在后端协议文档或设备描述符里能找到。它在过滤条件中作用巨大，能避免用户从一堆设备里选错。
• reportId是报告编号。由于 HID 设备可以定义多个报告，我为了区分不同通道统一用了reportId=1。这是自定义协议的一部分，不是系统规定死的值。

实际测试的时候，我第一次拿到的数据字节序与文档不一致，后来发现设备配置了字节逆序，本地做一个reverse再解析即可。这是非常典型的设备差异问题。

注意：如果你发现拿到的数据出现“卡号顺序错乱”或“少一位”，大概率不是 WebHID 的问题，而是设备本身的字节序、掩码位宽的差异。请优先比对协议文档，而不是反复调试前端解码。

5. 踩坑实录与常见问题排查

这部分内容来自我实践中的直接体验，比文档更有参考价值。

5.1 “设备被系统独占”导致打不开

最常见的一种失败是：device.open()抛错，提示Unable to open HID device。原因往往是设备已被系统输入服务占用。

• 键盘与鼠标：日常输入设备，系统占用严重，网页通常拿不到输入报告。自定义按键板如果被识别为键盘，也会遇到这个情况。
• 解决办法：在设备固件端设置正确的 Usage Page 和 Usage，把它定义成“非键盘、非鼠标”的 HID 设备。或者干脆选择扫码枪、读卡器这类不太被系统抢占的设备。

这是一个典型的硬件+软件联调问题。如果研发阶段发现打不开，不要纠结浏览器，先确认设备描述符里自己是“什么身份”。

5.2 页面刷新后提示授权失败

有同学反映，第一次页面能授权成功，刷新后requestDevice()反而不能弹窗了。原因很直接：requestDevice()必须由用户手势触发。刷新后如果立即在DOMContentLoaded里调用它，浏览器会拦。

正确做法：加载后先尝试getDevices()恢复已授权设备；只有用户点击“连接另一台设备”按钮时，才去调用requestDevice()。

5.3 inputreport 事件收不到数据

设备明明在正常上报，浏览器却没触发事件。大概率原因如下：

1. 设备没有被成功打开（用device.opened检查）；
2. 电脑上的其他程序抢先占用了设备（关掉厂商自带的配置工具即可）；
3. 数据是 Feature Report，不是 Input Report，需要receiveFeatureReport()主动读取；
4. 设备的上报格式是中断传输但浏览器没有正确绑定报告 ID。

排查顺序建议是：先重新打开设备 → 关闭其他占用程序 → 检查报告描述符 → 最后看代码。

5.4 数据解析结果永远不对

这不是 WebHID 的 bug，而是协议理解的偏差。HID 数据包里的“位”和“字节”是严格按照描述符定义的。最容易出错的是：

• 模拟量轴：比如摇杆 X/Y 轴各占 10 位，可能跨字节。
• 开关组：多个按键连续放，需要按位拆。
• 符号位：部分设备使用有符号数值，需要按补码处理。

解决方案就是我在前文写的extractBits函数，配合设备文档逐字段联调。我踩过最大的坑是某个设备把“逻辑最大值”标成了 1023，但实际发送时用的是 1024 范围内的值，导致边界判断不准。后来直接打印所有字节并对齐硬件波形图才定位到问题。

实践心得：连接成功后的第一步永远不要做复杂业务解析。先把原始字节流完整打印出来，再从文档里确认这些字节从哪里开始到哪里结束。一次能打通，后面就不会出幺蛾子。

5.5 Windows 上设备枚举正常但打不开

Windows 对 HID 设备的管理有自己的脾气。某些设备在“系统设备”列表里可见，但 WebHID 无法打开，原因大多和“设备接口限制”或“驱动层的过滤器驱动”有关。遇到这种场景，尝试以下顺序排查：

1. 确认设备没有在其他进程中被独占；
2. 尝试拔插一次设备，让系统重新枚举；
3. 查看设备管理器里有没有黄色感叹号；
4. 换一个 USB 口（尤其是用扩展坞时，某些口供电不足会导致设备唤醒异常）。

5.6 常见问题速查表

6. 多场景下的 WebHID 应用拓展思路

6.1 游戏外设的网页直调

游戏手柄是另一个很典型的 WebHID 场景。浏览器有 Gamepad API，但它是相对高层、只提供标准键值。WebHID 则能拿到手柄的原始 HID 报文，读取包括陀螺仪、扳机线性度、自定义背键在内的高级数据。想过没有，网页游戏不靠插件就能让第三方手柄实现“宏按键”功能，这在过去几乎不可想象。

我见过一个开源项目用 WebHID 实现手柄调试器，页面里直接画出按键矩阵与摇杆坐标，还能发送配置包改写手柄震动曲线。这类工具如果做成桌面应用，成本高不说，分发、更新都很麻烦，Web 版本一次部署到处用，真的是降维打击。

6.2 工业设备巡检页面

工业场景中大量设备还是采用 HID 接口，原因很简单：免驱、成熟、可靠。过去的巡检软件往往需要 WinForm 或 WPF 客户端。用 WebHID 做巡检面板后，只要浏览器开着，员工扫码枪一刷，设备参数、校准数值全部进入网页表格，直接入库。省掉了“安装客户端”这个环节，对产线的部署维护压力骤降。

同类应用还可以做到设备的批量校准页面、抄表页面，甚至可移动设备上用平板浏览器读取诊断状态。

6.3 医疗外设与无障碍设备的 Web 集成

医疗设备有很多以 HID 协议传输数据，比如体征检测仪、呼末二氧化碳监测仪、康复训练手柄等。这些设备传统上由专业软件对接，成本高。如果设备协议允许，WebHID 可以让浏览器直接承担可视化与存储的职能。同样，无障碍领域的辅助按键、轨迹球、头部追踪器等设备，也可以靠 WebHID 打通浏览器内的控制链路。

当然，医疗领域有严格的合规要求，WebHID 更适用的是内部研发验证和实验室环境，真正的患者场景还是要走更严谨的审批路径。但做为工程师，你知道浏览器能做这件事，等于多了一张手感极佳的工具卡。

6.4 浏览器作为硬件调试器

我最看好的方向是“浏览器即调试终端”。硬件开发过程中，调试 HID 描述符、验证报告数据、观察报文变化，过去要么用 Bus Hound，要么用厂商专用工具。现在 WebHID 完全可以做成一个跨平台通用调试台：打开网页，选择设备，实时看到所有上报报文，甚至能手动构造 Output Report 发送。对开发者来说，这是一套“零安装、零配置”的排查工具。

我自己就基于这个思路做过一个简化版调试页，功能只有一个列表 + 一个发送框，但整个硬件调试效率比之前用命令行工具快很多。

7. 最后分享几个实践里的小技巧

如果看完了整篇文章，你已经可以用 WebHID 做很多事了。但有几个细节不在 API 文档里，是我从项目里反复摸索出来的，很值得再写一遍。

7.1 善用collections字段做动态 UI

Device 对象上有一个collections字段，直接描述了设备报告结构。你可以遍历它，自动生成按键开关、数值滑杆的 UI 控件，而不需要硬编码每种设备的布局。对于需要兼容“一个系统多设备型号”的场景，这个字段几乎就是救命稻草。

for (const collection of device.collections) { console.log('Usage Page:', collection.usagePage); console.log('Usage:', collection.usage); for (const inputReport of collection.inputReports) { console.log(' 输入报告 ID:', inputReport.reportId, '大小:', inputReport.items.length, '字节'); } for (const outputReport of collection.outputReports) { console.log(' 输出报告 ID:', outputReport.reportId); } }

有了这些信息，页面能根据设备自动渲染调试面板，比写死 UI 高出一个层次。

7.2 不要轻视野外设备报告描述符的“内嵌数据”

有些自定义 HID 设备会在 Report Descriptor 中嵌入厂商私有数据段。浏览器在解析时可能不会完整暴露这些内容，但它有时会影响设备的工作模式。如果发现设备启动后表现异常，先尝试用专业解析工具读取设备真实描述符，而不是猜。

7.3 加一个“强制刷新设备列表”的按钮

调试阶段设备频繁插拔，授权列表可能会残留下“已经插拔但未从 list 里消失”的记录。此时调一下getDevices()即可刷新。我在工具页面上会专门放一个“刷新设备状态”按钮来干这事，省去每次刷新整个页面。

7.4 注意 HID 设备“输出报告”的发送频率

有的设备对输出报告的处理速度有上限，疯狂sendReport会触发设备内部缓冲溢出，效果是设备“死机”或丢消息。做连续控制（比如调整灯光亮度、电机转速）时，记得做发送节流：最小间隔限制在 10-20ms，或采用 requestAnimationFrame 配合实际需要。

const sendThrottle = (fn, delay = 20) => { let last = 0; return (...args) => { const now = Date.now(); if (now - last >= delay) { last = now; fn(...args); } }; }; const throttledSend = sendThrottle((data) => { device.sendReport(0, data); }, 20);

这个节流函数虽然简单，但能防止你调试时手滑把设备搞挂。

7.5 权限持久化后的撤销问题

用户如果不想让某个网站再访问设备，浏览器设置里可以撤销授权。但你的网页代码没办法主动触发“撤销”操作。所以产品设计上，要明确告诉用户“撤销授权需要去浏览器设置”。这也算一个不算常见但值得记住的小知识。

8. 结尾：跳出框架看 WebHID

WebHID 只是浏览器能力扩展的一个缩影。它的价值不只是“前端能连接硬件”，更深层的是它把硬件交互的门槛大幅降低。过去写一个外设工具，散落的环节包括开发环境、驱动兼容、软件分发、跨平台适配。现在打开浏览器，一切都在眼前。

当然，它也有自己的边界——不是所有设备都适合、用户授权机制有约束、某些平台对 HID 的访问限制仍然存在。但这不妨碍它成为一个具备战略价值的技术方向。对企业和独立开发者来说，WebHID 意味着可以把手伸进物理世界，而不用先爬过客户端的围墙。

如果在读这篇文章的你也正打算尝试 WebHID，我建议从最小的 Demo 开始：找一个手边的 HID 设备，打开网页，看看能不能打印出第一段原始数据。一旦你把第一条inputreport打印出来，整座桥就通了。之后不管是做产品工具、数据中心巡检还是硬件调试台，都只是在这条数据通道上继续延伸。

我个人的体会是：浏览器和硬件的边界正在快速消融，WebHID 是这条路上最实用的一把钥匙。拿着它，去解锁你身边的外设吧。