浏览器鼠标回报率测试：实测数值为什么总在跳？
浏览器是如何计算 Hz 的
我们要搞清楚一个底层逻辑：JavaScript 根本没权限直接读取 USB 接口的原始 HID 报告。网页端的测试原理其实非常简单，它只是在记录两次 mousemove 事件之间的时间差。
具体的计算逻辑大致如下：
// 简化版的计算逻辑
const intervalMs = currentTime - previousTime;
const observedHz = 1000 / intervalMs;也就是说，如果两次事件之间刚好隔了 1 毫秒，算出来就是 1000Hz；如果隔了 8 毫秒，就是 125Hz。
从传感器到网页：漫长的链路
鼠标传感器捕捉到位移后，数据要走这么一段路才能被网页看到：
传感器/固件 → USB/无线传输 → 操作系统内核 → 浏览器进程 → JavaScript 事件循环。
因为路径太长，浏览器接收到的是经过 OS 调度后的“二手”数据。这里有个关键的技术坑：事件合并（Event Coalescing）。当鼠标回报率极高（比如 4000Hz 或 8000Hz）时，浏览器为了性能，会将多个输入事件合并成一个后再交给 JS 处理。这就导致你在网页上看到的数值永远无法真实反映高刷鼠标的硬件性能。
为什么数值不稳定？
如果你发现数值波动剧烈，通常是由以下几个变量导致的：
- 事件合并机制： 浏览器分发事件的频率并不总是恒定的。
- 系统调度干扰： 后台有个占用 CPU 较高的进程，可能会导致浏览器处理事件产生微小延迟。
- 操作习惯： 鼠标移动速度太慢，导致单位时间内触发的事件数不足，无法填满采样区间。
- 连接模式： 蓝牙连接的延迟波动远大于 2.4G 或有线连接。
如何获取相对准确的对比数据
虽然浏览器测试不能作为硬件认证，但如果你想对比“有线 vs 无线”或者“500Hz vs 1000Hz”，可以通过以下实操步骤降低误差：
1. 统一环境： 保持 DPI 不变，关闭所有占用资源大的后台软件。
2. 固定动作： 在测试区域内快速且连续地画圆圈，确保鼠标始终处于高速运动状态。
3. 多样本取值： 连续测试 3-5 次。
4. 看平均值而非峰值： 偶尔出现的一个 1200Hz 峰值通常是由于两次事件时间戳极近产生的计算误差，参考平均值（Average）才有意义。
如果你需要一个具体的实测对比方案，可以尝试这个流程：
- 开启 500Hz → 连续画圆 10 秒 → 记录平均值。
- 开启 1000Hz → 连续画圆 10 秒 → 记录平均值。
- 观察两组数据的差距是否接近 2 倍，以此判断驱动设置是否生效。
总结：这个工具能用来干什么？
不要把浏览器测试当成精密仪器，但它可以作为一个快速的状态检查工具。
比如，当你怀疑 USB Hub 导致信号衰减，或者想测试在不同浏览器（Chrome vs Firefox）下输入响应的差异时，这种测试是非常高效的。只要你意识到它测量的是“浏览器观察到的事件率”而非“硬件原生频率”，它依然是一个极具参考价值的实操指南。
具体测试可以尝试这个路径：https://pollingratetester.com/mouse-polling-rate-test/
