在浏览器对象模型（BOM）的体系中，开发者常常需要确认运行环境能否访问外部硬件，尤其是人机交互设备（HID）。传统BOM并未定义统一接口来列举键盘、鼠标、游戏手柄之外的专用HID外设，直到WebHID提案出现才补齐能力。所谓检测用户的HID设备支持，本质是在脚本运行阶段确认当前浏览器是否暴露了可用的HID操作入口，以及用户是否愿意授予页面访问权限。
基于navigator.hid的特性探测
最基础的手段是检查BOM下的navigator对象是否包含hid属性。由于WebHID规范将接口挂载在navigator.hid上，若其值不为undefined，说明浏览器编译时包含了相关代码。但仅仅判断存在性并不充分，因为某些实验性版本虽暴露对象，却在非安全上下文（如HTTP明文页面）中禁用全部方法。
因此实际探测应叠加安全上下文校验。通过window.isSecureContext可以确定页面是否处于HTTPS或localhost环境，WebHID要求必须是安全上下文才允许调用。下面代码展示了一个稳健的初步检测函数：
function isHIDApiPresent() {
// 检查navigator.hid是否存在且为对象
if (typeof navigator === 'object' && navigator.hid && typeof navigator.hid === 'object') {
// 必须处于安全上下文
if (window.isSecureContext) {
return true;
}
}
return false;
}
console.log('HID基础支持:', isHIDApiPresent());
这种探测方式的优势是实现简单、同步返回，不会触发用户授权弹窗，适合在页面初始化时快速分支。缺点是它无法反映浏览器内部策略开关，例如企业版Chrome通过组策略关闭了WebHID，此时navigator.hid可能仍存在但调用即报错。所以基础探测只是第一道防线，不能作为唯一依据。
通过requestDevice验证真实可用性
即便基础探测通过，也并不代表用户真正能够枚举或打开设备。WebHID采用了显式授权模型：脚本必须调用navigator.hid.requestDevice并传入过滤条件，浏览器才会向用户展示权限请求。若接口被策略禁用，该函数返回的Promise会直接拒绝。利用这一行为，可以把请求封装为可用性验证步骤。
以下示例在用户点击按钮后尝试请求一个通用HID设备，并根据结果标记环境状态。注意requestDevice只能在用户手势中调用，否则会被浏览器拦截，因此验证逻辑通常绑定在交互事件里：
let hidVerified = false;
async function verifyHIDWithUserGesture() {
try {
const devices = await navigator.hid.requestDevice({
filters: [] // 空过滤条件表示请求用户选择任意HID设备
});
if (Array.isArray(devices)) {
hidVerified = true;
console.log('用户已授权，可用设备数:', devices.length);
}
} catch (err) {
hidVerified = false;
console.warn('HID验证失败:', err.message);
}
return hidVerified;
}
document.getElementById('checkBtn').addEventListener('click', verifyHIDWithUserGesture);
这种验证手段的可靠性最高，因为它走通了从API调用到系统权限的完整链路。代价是必须依赖用户操作且会产生界面中断，不能用于静默加载场景。工程上建议将基础探测用于页面渲染分流，将requestDevice验证用于真正需要通信的功能模块入口，两者互补。
另外，部分嵌入式WebView（如安卓微信旧版内核）会删除navigator.hid引用，此时基础探测直接返回否；而桌面版Chrome若被管理员限制，则基础探测为真但验证抛错。记录验证错误类型有助于上报兼容矩阵，例如区分“缺失接口”和“策略拒绝”两类情况来指导后续降级方案。
兼容性降级与运行时监控
当确认环境不支持或用户拒绝HID时，应用应当切换到替代通道，例如引导下载本地驱动程序、使用传统键盘事件模拟，或通过WebSocket连接本机代理服务转发HID数据。降级不是简单隐藏按钮，而是要在BOM层面监听navigator.hid的后续变化，因为浏览器插件启用可能让接口晚于页面加载出现。
可以通过定时轻量轮询或defineProperty劫持来感知接口注入，不过更推荐在关键操作前重新执行一次基础探测。下面的代码演示了在尝试通信前做最终检查，并依据结果选择WebHID或降级逻辑：
async function sendHIDCommand(reportId, data) {
if (!isHIDApiPresent()) {
return fallbackSend(reportId, data);
}
try {
const devices = await navigator.hid.requestDevice({ filters: [{ vendorId: 0x1234 }] });
if (!devices.length) {
return fallbackSend(reportId, data);
}
const device = devices[0];
await device.open();
await device.sendReport(reportId, data);
await device.close();
return true;
} catch (e) {
console.error('HID发送异常，走降级', e);
return fallbackSend(reportId, data);
}
}
function fallbackSend(reportId, data) {
// 例如通过HTTP转发到本地服务
console.log('使用降级通道发送', reportId, data);
return false;
}
运行时监控还应覆盖设备热插拔。WebHID提供navigator.hid.addEventListener('connect', ...)与disconnect事件，在已获授权的前提下可以实时更新设备列表。若初始检测时用户未接入硬件，后续插入也能被捕获，从而提升BOM下HID支持的感知完整性。
综合来看，BOM中检测HID设备支持不是单点判断，而是“静态接口存在性加动态权限验证加持续事件监控”的三层结构。忽略任何一层都会在特殊浏览器或企业环境中产生误判，进而让核心功能不可用。开发者应在架构初期就将这三步嵌入环境适配模块，才能稳妥地借助WebHID拓展网页与外设的交互边界。