手柄在网页可用但在游戏无反应，因操作系统将同一手柄分为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）。必须借助中间层。

HTML Text Extract

从HTML页面（URL、文件或标准输入）中提取主体内容文本，去除导航、页脚、广告和模板文本。可直接传递给readability_check或其他文本工具。

下载

• 前端用 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，绕过浏览器沙箱限制，适合做定制化手柄面板

真正麻烦的不是读手柄，而是跨进程注入输入——浏览器安全模型天然排斥这事。别指望纯前端搞定，得接受本地服务或游戏端配合这个事实。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！