90%的手柄连接问题源于未通过浏览器用户交互许可关：必须在click等用户手势回调中首次调用navigator.getGamepads()，且仅HTTPS/localhost有效；需用requestAnimationFrame轮询并校验connected和timestamp；摇杆需设死区阈值，按钮用帧间对比检测，依gamepad.id动态映射。
手柄连不上、读不到数据、按了没反应——90% 的问题不是手柄坏了，而是没过浏览器的“用户交互许可关”。
为什么 navigator.getGamepads() 总返回空数组或全是 null
这是最常卡住开发者的起点。浏览器不会在页面加载完就主动给你手柄数据，它要求一次明确的用户手势（click、keydown、touchstart）作为授权信号。
- 必须在用户触发的事件回调里首次调用
navigator.getGamepads()，比如：button.addEventListener('click', () => { const pads = navigator.getGamepads(); console.log(pads[0]); // 此时才可能有真实数据 }); - HTTP 协议页（非
https://或localhost）在 Firefox 和新版 Chrome 中直接禁用 API，file://协议必然失败 -
navigator.getGamepads()返回的是快照数组，索引固定但内容动态：已断开的手柄位置仍为null，不能靠pads.length判断活跃数
怎么可靠捕获手柄连接（gamepadconnected 事件不总触发）
该事件依赖系统驱动和浏览器实现，USB 热插拔在 macOS/Linux 上容易静默失败，蓝牙手柄休眠后也可能不发断开事件。
- 不要只监听
gamepadconnected就以为万事大吉；必须配合requestAnimationFrame轮询navigator.getGamepads() - 轮询时检查每个
Gamepad对象的connected属性和timestamp：若timestamp长时间未更新，说明设备已掉线但没触发事件 - 缓存
e.gamepad实例（来自事件），它比从数组里再查getGamepads()[e.gamepad.index]更可靠，避免索引错位
读取摇杆和按钮时为什么数值乱跳或映射错位
摇杆存在物理死区，按钮索引跨设备不统一，硬写 buttons[0] 或 axes[1] 必然翻车。
立即学习“前端免费学习笔记（深入）”；
- 摇杆过滤建议：
Math.abs(axis) > 0.15才视为有效输入；静止时 ±0.05 浮动是常态 - 按钮按下检测别轮询
pressed字段，改用帧间对比：prevBtn.pressed === false && currBtn.pressed === true -
gamepad.id是唯一可用线索（如含"xbox"或"playstation"），据此切换映射表；gamepad.mapping字段几乎不可靠，多数手柄返回空字符串 - 轴数量不固定：Xbox 手柄通常暴露 4 轴（左/右 XY），但某些蓝牙手柄只报 2 轴（仅左摇杆），务必用
gp.axes.length动态判断
为什么手柄输入延迟高或断续
状态不是实时推送的，浏览器只在每帧渲染前更新一次 getGamepads() 快照。在 setTimeout 或事件回调里反复调用，反而会读到过期数据。
- 必须把轮询逻辑塞进
requestAnimationFrame循环，才能保证与渲染同步、延迟最低 - 避免
setInterval：它不绑定渲染节奏，容易造成输入丢帧或重复采样 - 部分手柄（如 PS4 DualShock 4 有线连接）在 Chrome 110+ 后需手动启用
chrome://flags/#enable-gamepad-extensions
真正麻烦的从来不是“怎么读”，而是“什么时候能开始读”和“读到的值怎么信”。用户没点一下，浏览器就当你是可疑脚本；摇杆中心偏移 0.15，你却用 0.01 当阈值——这些细节不抠清楚，手柄永远在“连上了但没完全连上”的状态来回横跳。
