webhid api 出于安全与隐私保护，明确禁止访问鼠标、键盘等通用输入设备的低级 hid 报告；浏览器会主动屏蔽此类设备，防止恶意键鼠监听行为。当前 web 平台无标准 api 支持真正意义上的低级鼠标/键盘事件捕获。
webhid api 出于安全与隐私保护，明确禁止访问鼠标、键盘等通用输入设备的低级 hid 报告；浏览器会主动屏蔽此类设备，防止恶意键鼠监听行为。当前 web 平台无标准 api 支持真正意义上的低级鼠标/键盘事件捕获。
WebHID（Human Interface Device API）虽被设计为提供对 HID 设备的底层访问能力，但其实际权限受到严格约束。关键事实是：浏览器内建的 WebHID 实现主动将标准鼠标（Usage Page: 0x01, Usage: 0x02）和通用键盘（Usage Page: 0x01, Usage: 0x06）列入硬编码屏蔽列表（blocklist），无论设备厂商 ID、产品 ID 或报告描述符如何，均无法通过 navigator.hid.requestDevice() 成功获取或监听其 inputreport 事件——这也是你点击授权后 inputreport 事件监听器始终不触发的根本原因。
该屏蔽机制并非 Bug，而是 W3C 规范与主流浏览器（Chrome ≥ 89、Edge ≥ 89）共同实施的安全强制策略。其核心逻辑在于：若允许网页直接读取原始 HID 输入流（如按键扫描码、原始坐标增量），攻击者即可绕过 DOM 事件隔离，构建隐蔽的跨站点键盘记录器（keylogger）或鼠标轨迹窃取器，严重威胁用户凭证与操作隐私。该 blocklist 公开维护于 WICG/webhid/blocklist.txt，其中明确包含：
# Standard mouse and keyboard devices are blocked by default 0x01:0x02 # Generic Desktop Controls → Mouse 0x01:0x06 # Generic Desktop Controls → Keyboard
✅ 可行的替代路径（受限但合规）：
- 标准 DOM 事件：使用 keydown/keyup/keypress（键盘）与 mousemove/mousedown/wheel（鼠标）等事件，适用于绝大多数交互场景。注意：它们已过浏览器合成与过滤（如 Ctrl+C 可能被拦截、部分快捷键无 keydown），且不暴露原始硬件扫描码或绝对坐标。
- Pointer Events API：对高精度输入（如绘图板、触控笔）更友好，支持 pressure、tangentialPressure、tiltX/Y 等扩展属性，需设备与驱动支持。
- Gamepad API：仅适用于符合 USB HID Game Controller 协议的游戏手柄，不适用于键盘/鼠标。
- Web Serial（需用户主动选择端口）：若目标设备是自定义微控制器（如 Arduino + HID 键盘固件），可改用串口通信并自行解析协议，但需用户手动选择 COM/USB 端口，且不适用于原生 HID 键鼠。
⚠️ 重要注意事项：
- 不要尝试通过伪造 filters（如指定 vendorId/productId）绕过屏蔽——现代浏览器在设备枚举阶段即完成 blocklist 匹配，requestDevice() 调用会直接拒绝或返回空数组。
- navigator.hid.getDevices() 返回的设备列表中，被屏蔽的键鼠设备永远不会出现，即使物理连接正常。
- 所有 WebHID 操作必须在安全上下文（HTTPS 或 localhost）中执行，且需显式用户手势触发（如按钮点击），不可自动启动。
? 总结： WebHID 的设计哲学是“能力与责任对等”——它赋予网页访问专用 HID 设备（如医疗传感器、工业控制器、定制外设）的能力，但以彻底封禁通用输入设备的低级访问为代价。开发者应基于此前提重构需求：若需记录用户操作，优先采用语义化 DOM 事件并明确告知用户用途；若需硬件级控制，请考虑原生应用（Electron/Tauri）或 PWA 配合系统级代理服务。Web 平台的安全边界，不应被视作限制，而应作为构建可信用户体验的基石。
