Gamepad API 会骗你：JavaScript 读取控制器输入的实用指南
内容提要
Gamepad API 虽小，但需轮询获取数据，且浏览器会过滤未归零的轴值，导致漂移手柄被误报为正常。无法通过ID识别硬件，应基于能力检测。区分漂移与人为操作需结合均值幅度和方向一致性双重判断。测试时务必使用已知故障手柄验证。
延伸解读
浏览器为何会“隐瞒”漂移？
Chromium 的轴值过滤机制是导致漂移手柄被误报为正常的关键。浏览器会强制将未“归零”过的轴值报告为 0，直到它观察到该轴低于 0.1 的阈值。这意味着漂移越严重，手柄越可能被无限期屏蔽，因为其轴值从未低于阈值。理解这一机制有助于开发者避免在页面加载后立即信任首帧数据，而应等待轴值“解锁”后再做判断。
识别硬件：别依赖 ID 字符串
pad.id 并非可靠的硬件标识，尤其在 Windows 和 macOS 上，不同厂商的设备可能返回相同或相似的字符串。例如，Xbox 兼容手柄和第三方克隆产品在 Windows 上可能显示完全相同的 ID。因此，开发者应基于能力检测（如轴数、按钮数、是否支持振动）来适配功能，而将 ID 仅用于显示或用户确认，避免因解析 ID 导致错误渲染。
区分漂移与人为操作的双重门控
仅靠阈值和定时器判断漂移容易误报，因为用户缓慢旋转摇杆时，轴值可能长时间超过阈值。有效的检测需结合两个条件：平均幅度低于 0.6（漂移通常偏移较小）和方向一致性高于 0.9（漂移方向稳定，人手会自然晃动）。这种双重门控能显著降低误报率，但无法区分刻意保持静止的摇杆，因此最好在要求用户松开摇杆的特定场景下检测。
测试工具必须用故障手柄验证
如果测试工具只在正常手柄上运行，就无法发现浏览器过滤轴值等隐藏问题。作者强调，使用已知故障的手柄（如漂移手柄）进行测试，才能暴露 API 的异常行为，确保工具真正有效。这提醒开发者，在构建硬件相关工具时，应覆盖异常场景，否则可能给用户错误结论。
Q&A
为什么使用 Gamepad API 时必须轮询而不是监听事件？
Gamepad API 没有轴变化或按钮按下的事件，只有连接和断开事件。要获取实时输入，必须在 requestAnimationFrame 循环中反复调用 navigator.getGamepads()，因为每次调用返回的是快照，缓存对象会导致数据冻结。
为什么漂移的手柄在浏览器中可能被报告为正常？
Chromium 会过滤未归零的轴值：每个轴必须至少一次报告幅度低于 0.1 才会开始传递真实值。漂移严重的手柄可能永远达不到这个阈值，因此浏览器会一直报告 0，导致漂移被隐藏。
如何区分摇杆漂移和人为操作？
通过两个条件判断：1) 平均幅度小于 0.6（漂移通常是小偏移）；2) 方向一致性高，即平均向量长度与平均幅度的比值大于 0.9（漂移方向稳定，人手会晃动）。同时满足才判定为漂移。
为什么不能通过 pad.id 识别手柄型号？
pad.id 是浏览器生成的字符串，在 Windows 上 XInput 设备不包含厂商和产品 ID，第三方克隆与正品显示相同；macOS 上 DualShock 4 显示为通用名称。因此应基于能力（如 mapping、轴数）进行功能检测，而不是依赖 ID。
测试手柄时为什么必须使用已知故障的手柄？
因为许多 API 行为只在故障硬件上显现，健康手柄会隐藏这些问题。只用正常手柄测试无法验证漂移检测等功能，测试结果不可靠。
Gamepad API 有哪些已知限制？
振动功能不可移植，需特性检测；非标准映射时轴和按钮顺序不确定；蓝牙轮询间隔不稳定；浏览器对新控制器的支持滞后于硬件。
