手柄在网页可用但在游戏无反应，因操作系统将同一手柄分为HID（浏览器Gamepad API）和DirectInput/XInput（游戏）两套隔离通道；网页无法直接模拟系统输入，需本地服务中转，存在延迟与权限限制。
HTML 手柄（Gamepad API）和原生游戏控制不冲突，但默认互不感知——浏览器里按手柄不会触发游戏内按键，游戏里也收不到 navigator.getGamepads() 的数据。
为什么手柄在网页里能用，但在游戏里没反应？
因为操作系统把同一物理手柄分成了两套输入通道：一套走 HID 协议进浏览器（通过 Gamepad API），另一套走 DirectInput / XInput / SDL2 进本地游戏进程。两者底层隔离，没有共享事件流。
- 浏览器只监听
gamepadconnected、gamepaddisconnected和gamepadbuttondown等事件，不向系统或其它进程广播按键 - Steam 或 Windows 游戏通常绕过浏览器，直接读取硬件报告描述符，甚至会禁用浏览器对设备的访问（尤其启用“大屏幕模式”时）
- 部分手柄（如 DualShock 4 在 Windows 上）需驱动支持才能同时被网页和游戏识别；未装 DS4Windows 时，网页可能看到手柄，游戏却显示“未连接”
想用 HTML 做手柄中转代理，可行吗？
技术上可以，但有硬限制：现代浏览器禁止网页直接模拟系统级输入（比如触发 SendInput 或 uinput）。必须借助中间层。
- 前端用
navigator.getGamepads()读取状态，通过 WebSocket 或fetch发给本地服务（如 Node.js +robotjs或 Python +pynput） - 本地服务收到后，调用系统 API 模拟键盘/鼠标事件——这才能被游戏捕获
- 注意权限：macOS 需手动开启“辅助功能”授权；Windows 可能被 Defender 拦截；Linux 要加
uinput模块并赋权 - 延迟明显：典型链路是「手柄 → 浏览器 → 网络 → 本地服务 → 系统输入」，比直连高 30–100ms，格斗或音游慎用
有没有更轻量的替代方案？
如果目标只是“让网页操作映射成游戏可用输入”，优先考虑游戏自身支持的协议，而非硬桥接。
立即学习“前端免费学习笔记（深入）”；
- 部分游戏（如 RetroArch、Cemu）支持 UDP 控制协议，可写 JS 直接发包，无需本地代理
- Steam 支持“控制器配置”，能把手柄任意按键映射为键盘键（例如把左摇杆映射成
WASD），此时网页只需触发KeyboardEvent（用dispatchEvent模拟），游戏就能响应 - Electron 应用可直接调用
robotjs，绕过浏览器沙箱限制，适合做定制化手柄面板
真正麻烦的不是读手柄，而是跨进程注入输入——浏览器安全模型天然排斥这事。别指望纯前端搞定，得接受本地服务或游戏端配合这个事实。
