鼠标回报率测试在线

在测试区里连续画圈，页面就会数这一页每秒收到多少条指针上报，折算成回报率（轮询率）：特大读数给当前值，旁边是峰值、移动时的平均值和归到的档位（125／250／500／1000／2000／4000／8000 Hz）。下面还有最近 5 秒的实时曲线和上报间隔直方图，一眼看出间隔稳不稳；采样优先用未合并的原始上报，退到合并事件，再退到裸事件，界面上如实写明当前用的是哪一种以及它能测到的上限。读数稳定、卡在 125、在两档之间跳，各自对应一段人话结论。

怎么用

打开这一页，把指针移进那块虚线框起来的测试区，连续快速画圈，读数立刻就出来了。不用点任何按钮，也不用等它「开始检测」。

一、测试区与大读数

正中最大的那个数字是当前回报率，它只看最近 200 毫秒：这一小段时间里收到了多少条上报，就折算成每秒多少次。下面小字会同时告诉你这对应多长的上报间隔，例如「约每 1.00 ms 收到一条上报」。

手一停，读数会掉回「—」。这不是故障：鼠标静止时本来就不会满速上报，多数鼠标在没有位移时干脆不发数据。要读数稳，就得连续、匀速地画大圈，别画一下停一下。

测试区里那条跟手的橙色拖影只是给眼睛一个反馈，方便你确认页面确实在收事件；统计本身只用到「事件条数」和「时间戳」，和指针画在哪里没有关系。

二、四个读数

看结论请以「归档」和曲线为准，别盯着峰值。

三、采样方式：页面用的是哪一种

网页拿不到鼠标固件里的设定，只能数自己收到了多少条事件，而能收到多少条，取决于浏览器给了哪种接口。页面按下面的顺序退让，并把当前用的那一种如实写在工具栏下面：

1. 未合并的原始上报（pointerrawupdate，Chrome 系桌面浏览器有）：不跟着画面帧走，是网页里最接近真实回报率的口径；
2. 合并事件（pointermove ＋ getCoalescedEvents()）：浏览器每帧只给一条事件，但会把这一帧里攒下的原始上报整批交出来，所以也能测到高于屏幕刷新率的值；
3. 裸事件（只有 pointermove）：每帧最多一条，读数的天花板就是屏幕刷新率（常见 60、120、144），这时候量到的不是鼠标的回报率。

工具栏的下拉可以手动切，三种方式的结果放在一起对照着看很有意思：同一只 1000 Hz 的鼠标，用裸事件测出来往往正好等于你的屏幕刷新率。切换会清零重测，选择记在这台设备的浏览器里（键名 hi8-huibaolv-prefs）。

四、实时曲线

曲线画的是最近 5 秒，每 100 毫秒一个点：绿色柱子是那一小段的折算频率，橙色折线是趋势，横着的虚线是当前归到的档位。

怎么看：柱子高度齐平、顶着虚线＝上报很稳；柱子忽高忽低＝间隔时长时短；中间掉到底的那几段，就是你手停下来的时候。

五、上报间隔直方图

这是这一页比只给一个数字的工具多出来的一块。它把最近 5 秒里每两条上报之间隔了多久分进八个桶：0.125、0.25、0.5、1、2、4、8 毫秒和「更久」。桶的边界取相邻两档的几何中点，所以 1.0 毫秒会稳稳落在「1 毫秒」那一桶里，不会因为 0.03 毫秒的抖动跳到隔壁。占比最高的那一根标成品牌橙。

• 集中在一根柱子上：上报间隔很规律，连接稳定；
• 散在相邻两三根上：有轻微抖动，通常是浏览器调度或手速变化，正常；
• 一大堆落在「更久」里：中间有明显的丢包或长时间空档，往下看结论那一节。

六、结论卡

页面每隔半秒重算一次结论，按「没测够 → 动得太慢 → 在两档之间跳 → 被帧率卡住 → 读数毛糙 → 卡在 125 → 稳定」的顺序挑一条，每一条都带着下一步该动哪里。它只描述现象和常见原因，不会替你判定鼠标坏没坏。

七、触屏设备上

手机和平板没有鼠标，这一页会在顶部如实说明，同时把同一套统计用在触摸上报上：量的是这块触摸屏每秒上报多少次触摸位置。手机屏常见 60 到 240 Hz，和鼠标的回报率是两回事，别拿来互相比较。

八、清零与存了什么

点「重新开始」把所有读数清零，重新测一轮。测出来的数字全都只在这个页面里算，刷新就没了；这台设备上只留一样东西，就是你选的采样方式。

怎么看结果

测完最想知道的是「我这个正常吗、不正常该动哪里」。

一、先对着档位表认一下

归档用的是倍数比而不是差值比：300 Hz 离 250 比离 500 近，所以它会被归到 250。

二、几种常见现象和它们通常意味着什么

读数稳定贴着某一档。 这就是你这只鼠标在当前连接方式下的工作状态，和厂商标称对得上就没事。

稳稳卡在 125 Hz。 很多鼠标出厂默认就是 125 Hz，办公完全够用。想更高，去驱动软件里调，或者找找机身上的回报率切换键；如果你用的是蓝牙，先换成 2.4 GHz 接收器或者插上线再测，蓝牙通常只有 125 Hz 上下。

读数在两档之间大幅跳动。 常见原因有三个：一是无线鼠标的省电策略，长时间没有连续动作时会降频上报，动起来才升回去；二是USB 链路被挤，鼠标插在集线器、显示器的 USB 口或笔记本扩展坞上，和别的设备抢带宽，直接插主机后面的接口再测；三是后台有程序占着 CPU，下载、杀毒扫描、视频通话、另一个标签页在播视频都算。换台电脑再测一次，能帮你把「鼠标的问题」和「这台电脑的问题」分开。

读数上限正好等于屏幕刷新率。 比如读数死死贴着 60 或 144，那多半不是鼠标的问题，而是浏览器只给了裸事件。看一眼工具栏下面写的采样方式，换 Chrome 系的桌面浏览器再测一次。

读数偏低，而且手一慢就更低。 页面会提示「再快一点」。鼠标静止或慢移时本来就不满速上报，这是传感器与驱动的正常行为，不是毛病。

一堆间隔落进「更久」那一桶。 说明中间有肉眼看不见的空档。无线鼠标离接收器太远、接收器插在 USB 3.0 接口旁边（2.4 GHz 频段会被干扰）、鼠标垫下面压着金属，都会这样。把接收器用延长线挪到桌面上靠近鼠标的地方，是最立竿见影的一招。

三、这一页量不到的东西

• 厂商口径的真实回报率：网页只能数自己收到多少事件，浏览器丢掉的那部分看不见；
• 鼠标的整体延迟：从按下到画面响应还要加上传感器、系统、显示器的时间，这一页只管上报这一段；
• DPI（精度）：和回报率是两回事，要量去 鼠标 DPI 测试；
• 按键有没有毛病：单击变双击、滚轮回滚要去 鼠标双击测试 和 鼠标测试。

常见问题

为什么峰值经常比归档高一大截？

因为峰值是瞬时窗口里出现过的最大值，而浏览器交付事件的节奏并不均匀：有时一帧里攒了十几条一起给，这一小段的折算频率就会顶得很高。所以结论看的是中位数——要超过一半的读数都到了某个量级，才算数。

为什么每次测出来都差几十赫兹？

回报率的实现是「每隔固定时间轮询一次」，理论上很规律，但事件要经过系统、浏览器进程、页面脚本几道手，每一道都会带来零点几毫秒的抖动。980、1010、1030 这种尾数是正常的。归档按倍数比算，两档的分界落在它们的几何中点（500 与 1000 之间是 707 Hz），所以这类尾数不会把结果带到隔壁档去。

一边开着游戏或直播软件，一边测，有影响吗？

有，而且不小。那类软件会持续占用 CPU 与 USB 带宽，表现为读数整体偏低、直方图变散。测之前尽量把它们关掉，测完再开。

有线和无线，读数会差很多吗？

看连接方式，不看有线无线本身。有线和 2.4 GHz 接收器通常都能跑满标称档位；蓝牙则普遍只有 125 Hz 上下，而且更容易出现上报间隔忽长忽短。同一只支持三模的鼠标，三种连法各测一轮，差别会很直观。

回报率低是不是就该换鼠标了？

不一定。先把三件事排除掉：驱动里的档位设置、连接方式（蓝牙换成接收器或线）、USB 接口（从集线器换到主机直连）。这三样占了绝大多数「读数上不去」的情况。都试过还是不对，再考虑换台电脑测一次确认。

这一页和站内那几个鼠标相关的页怎么分工？

鼠标测试 是综合体检：五个按键、滚轮、轨迹连不连续，回报率在那边只是一个读数。鼠标双击测试 只查一件事——微动开关是不是按一下出两下。鼠标 DPI 测试 量的是精度，鼠标灵敏度转换器 帮你把游戏灵敏度换算过来。想比手速去 CPS 手速测试，想测屏幕去 屏幕刷新率测试。这一页只围着回报率做深。

原理与冷知识

一、「轮询」这个词是从 USB 协议里来的。 USB 设备不能想说话就说话，得等主机来问。主机按固定节拍逐个问一遍所有设备「有新数据吗」，这就是轮询。鼠标在描述自己的时候会报一个「希望多久被问一次」的间隔，主机按这个间隔安排。所以回报率不是鼠标单方面能决定的，是主机和设备商量出来的结果。

二、为什么最高是 1000 Hz，后来又冒出 8000 Hz。 USB 1.1 全速设备的帧长正好是 1 毫秒，一帧最多被问一次，所以那个年代的天花板就是 1000 Hz；而默认的轮询间隔是 8 毫秒，于是 125 Hz 成了一代鼠标的出厂默认值，直到今天还有大量办公鼠标停在这一档。USB 2.0 高速设备把一帧切成 8 个微帧，每个 125 微秒，于是 8000 Hz 有了物理基础——但这要求鼠标、接收器、主板、驱动全链路都支持。

三、回报率省下来的时间其实很短。 从 125 Hz 提到 1000 Hz，平均等待从 4 毫秒降到 0.5 毫秒，省了三毫秒半，这在快速甩动时是能感觉到的。但从 1000 Hz 再提到 8000 Hz，平均等待只从 0.5 毫秒降到 0.0625 毫秒，省下的时间比一帧画面（144 Hz 下是 6.9 毫秒）的百分之七还少。收益递减在这里非常陡，而代价——无线续航、CPU 占用、兼容性——是线性增长的。

四、高回报率是要 CPU 买单的。 每一条上报都要经过驱动、系统、应用几层处理。8000 Hz 意味着每秒八千次中断与事件分发，在一些游戏引擎里会实实在在地表现为帧率下降。这也是为什么不少玩家在试过最高档之后，反而退回 1000 Hz。

五、浏览器为什么要合并鼠标事件。 早年网页每收到一条鼠标移动就得跑一次脚本，高回报率鼠标能把页面拖垮。于是浏览器改成「每一帧只派发一条 pointermove」，同时提供 getCoalescedEvents() 让需要精细轨迹的页面（画板、签名、手写）把这一帧里攒下的原始点整批取回来。后来又加了 pointerrawupdate，专门给那些「宁可自己承担性能代价也要最快拿到位置」的应用用——这一页正是靠它才测得到高于屏幕刷新率的值。

六、回报率、DPI、屏幕刷新率是三件不同的事。 回报率是多久说一次，单位赫兹；DPI 是每移动一英寸报出多少个计数，决定精度；屏幕刷新率是画面每秒换多少次，决定你看到的顺滑程度。三者都用得上，但谁也替代不了谁：1000 Hz 的鼠标配 60 Hz 的屏幕，你看到的仍然是每秒 60 次更新；高 DPI 配低回报率，快速甩动时轨迹一样会显得一段一段。

七、别用「鼠标刷新率」这个叫法。 市面上确实有人这么写，指的就是回报率，但它太容易和屏幕刷新率混淆——两者单位相同、数量级接近（144 与 125 只差一点），在论坛上互相误解的帖子非常多。说「回报率」或者「轮询率」，不会有歧义。