手柄测试
按键、摇杆、扳机各自按下去，看页面上对应的格子有没有反应。松手后还能标定一次漂移，判断摇杆是不是该换了。
连接手柄
浏览器只在收到一次真实输入后才会把设备暴露给页面，所以插上之后一定要按一下按键。死区只影响下面「死区后」那一列的显示，不会改写手柄本身。
实时读数 等待输入
按键
还没有读到手柄。插上设备后按一下任意按键，这里会立刻列出所有按键。
摇杆
轴数据要等手柄被识别之后才有。
设备信息
还没有读到设备名。按一下手柄上的任意键，浏览器才会把它暴露给页面。
Chrome 系浏览器会把常见手柄归一化成标准映射，Firefox 和 Safari 有时保留原始轴顺序。同一个手柄在两个浏览器里读数不同是正常的，判断故障请固定用一个浏览器对比。
这页能测出什么
能测出的是一次按键有没有被浏览器收到、摇杆有没有输出、扳机是只有开关还是真的有行程。这三件事覆盖了手柄最常见的故障：某个按键的微动失灵、摇杆电位器磨损导致漂移、扳机弹簧断了所以行程不对。它们都能靠读数直接看出来，不需要拆开设备。
测不出的是手感和延迟。延迟取决于手柄固件、连接方式（蓝牙还是 2.4 GHz 接收器）、系统轮询和游戏引擎，浏览器的 Gamepad 接口每秒只按刷新率读取若干次，读到的值本身就被限流了，所以这里不给毫秒级的输入延迟。想要低延迟，优先用有线连接，并且避开 USB 3.0 接口旁边的 2.4 GHz 接收器。
漂移的判断标准要按「最坏情况」而不是平均值来定。摇杆静止时读数会在零点附近小幅跳动，平均下来可能只有 0.01，但偶尔冲到 0.2 就足够让角色在游戏里慢慢转头。所以标定取三秒内的最大偏移作为结论，再按游戏里的实际影响分档：0.03 以内几乎无感，0.08 以内落在默认死区里，超过 0.15 就该考虑换摇杆模块了。
死区的算法要避免「推过死区之后突跳」。常见做法是简单截断，那样在死区边界上输出会从一个很小的值突然变成死区的大小，手感是一条台阶。这里用的是先减去死区、再按剩余范围重新缩放，输出从 0 连续增长，过渡是平滑的。
想顺手测一下键盘，用键盘按键测试；想确认显示器在快速移动时会不会拖影，用屏幕拖影测试；射击游戏里换算灵敏度可以看鼠标灵敏度换算。
常见问题
插上手柄页面没反应，要按什么吗？
要按一下手柄上的按键。浏览器出于安全和省电的考虑，不会在页面加载时主动枚举手柄，必须等到有一次真实输入才把它暴露出来。按下之后页面会立刻出现设备名，之后再刷新也能自动识别。
摇杆松手后数值不是 0，是不是坏了？
不一定。摇杆是机械结构，弹簧回中、轴心磨损、温度变化都会让静止值偏离零点几，这在所有手柄上都存在。真正影响游戏的是幅度：0.08 以内基本落在游戏默认死区里，感觉不到；超过 0.15 才开始出现「角色自己走」的现象。页面给的结论就是按这个标准分的。
死区应该调多少？
先从 0.08 开始试。死区太小会把手柄本身的漂移带进游戏，太大会吃掉小幅度推杆的精度，射击类游戏尤其明显。如果漂移在 0.08 以内，交给游戏自己的设置就行，不必在系统层再叠一份。
扳机按下去只显示 0 和 100，没有中间值？
说明这个扳机在系统里被当成了普通按键，而不是模拟轴。部分第三方手柄、以及通过某些转接器连接的手柄会这样上报，游戏里也就没法做油门力度这种线性输入。驱动或转接器的固件更新有时候能解决。
同一个手柄在 Chrome 里正常，Firefox 里按键全错？
两者的映射策略不同。Chrome 会把大部分常见手柄归一化成规范里的标准布局，Firefox 和 Safari 有时直接暴露原始轴顺序和按键顺序。这不是手柄的问题，判断故障时固定用一个浏览器做对比即可。
震动按钮没反应怎么办？
震动依赖浏览器的 Gamepad Haptic Actuator 接口，目前主要是 Chromium 系支持，Firefox 和 Safari 基本没有。另外部分手柄只在有线连接或特定驱动下才允许震动，蓝牙连接时可能只上报按键不响应马达。
无线手柄连着但一直掉线？
先看电池电量，低电量时手柄会优先保住输入、放弃震动，表现就是能操作但马达不转。其次看 2.4 GHz 干扰，USB 3.0 接口和无线接收器靠得太近是常见原因，把接收器挪到机箱前面板通常能改善。