滑鼠回報率：1000Hz 真的比 500Hz 好嗎？

把回報率從 500Hz 提高到 1000Hz，會把回報間隔從 2 毫秒縮短到 1 毫秒，在整條遠長得多的延遲鏈中，只改善其中一個環節的 1 毫秒。實務上，這點增益在螢幕更新間隔、GPU 幀時間與人體反應速度的對照下完全無感——後三者都大上一個數量級。唯有當其他所有環節都已經夠快（高更新率螢幕、穩定高幀率、全程低系統延遲）時，更高的回報率才有幫助。對文書工作與休閒遊戲而言，500Hz 功能上毫無差別，卻能消耗更少的處理器時間，並為無線裝置省下電力——不過當你需要時，現代 2.4GHz 接收器確實也支援 1000Hz。

用數字說明

從 125 Hz 提升到 1000 Hz 可減少約五毫秒的平均等待時間。從 1000 Hz 提升到 8000 Hz 則再減少半毫秒——而這半毫秒隱身在另外十五毫秒鼠標無法縮短的延遲之中。

如今滑鼠廠商都把 8000Hz 回報率當作頭號規格來宣傳，話裡話外都在暗示：低於這個數值就是在拖累你的表現。從 500Hz 到 1000Hz 的提升，在規格表上確實貨真價實，但它在螢幕上造成的實際差異，遠比那個「翻倍」的數字所暗示的小得多；而追求更高回報率所付出的代價，行銷文宣卻隻字未提。以下是老實的帳。

回報率究竟描述的是什麼

你的滑鼠會以固定頻率取樣自身位置，並把資料傳送給電腦。在 500Hz 下，它每 2 毫秒回報一次；在 1000Hz 下，每 1 毫秒一次；在 8000Hz 下，每 0.125 毫秒一次。回報率越高，代表位置更新越頻繁，因此從你動手到游標回應之間的延遲「有可能」變得更短。

關鍵在於「有可能」三個字。回報只是延遲管線中的一個環節，而且幾乎從來不是最長的那個環節。

大家都在引用的算術，以及它略過的脈絡

1000Hz 與 500Hz 的差異，是回報間隔上的 1 毫秒。這就是在回報階段所能量測到的全部優勢；而由於移動可能發生在區間內的任意時間點，平均真正省下的時間更接近半毫秒。

現在把這點時間放進同一條管線的其他環節一起看：

把回報率翻倍所換來的這 1 毫秒，相較於螢幕更新與畫面渲染根本是四捨五入的誤差，更比你自己的反應時間小了約兩百倍。正是這種比例關係，讓大多數玩家在盲測中確實無法分辨 500Hz 與 1000Hz——無論他們心裡預期會感受到什麼。

什麼時候 1000Hz 及以上才真正有用

唯有當鏈上的每一個環節都已經夠快時，更高的回報率才會產生價值。具體來說需要：

• 高更新率螢幕，落在 240Hz 到 360Hz 之間，讓螢幕真的能在低於 4 毫秒的間隔內呈現更新。
• 穩定且明顯高於 300 的高幀率，讓渲染好的幀足以填滿那些更新機會。
• 全程低系統延遲，包括直接接 USB、極少的背景處理、以及輸入路徑上沒有疊加層。

在那個狹窄、刻意優化過的競技窗口內，少數玩家能從 1000Hz——偶爾甚至是更高的回報率——中獲得實質價值。窗口之外，效益就崩塌到無法感知，因為瓶頸只是轉移到別處，而多出來的回報在影響到任何可見畫面之前就被合併或取樣掉了。

繼續拉高回報率的代價

更高的回報率不是免費的，超過 1000Hz 之後，取捨就變得很實質：

處理器負載

每一筆回報都會穿越作業系統的輸入堆疊，而且往往還有遊戲引擎。到了 4000Hz 到 8000Hz，這會消耗可量測的處理器時間；在較弱的系統上，由此導致的幀率下降甚至會增加整體延遲，而非減少它。

電池耗損

無線滑鼠在較高回報率下會消耗顯著更多的電力，8000Hz 更可能讓充電間隔的續航時間大幅縮短。

很少轉化為可見效益的回報

8000Hz 滑鼠每 0.125 毫秒回報一次，而 360Hz 螢幕每 2.8 毫秒才更新一次。兩幀之間會湧入二十多筆回報，而這些多出來的細粒度根本沒有用武之地。

回報率既不是瞄準品質，也不是 DPI

有兩種根深蒂固的混淆在扭曲購買決策：

• DPI 是感應器靈敏度，描述每英吋實體移動所對應的游標位移。它與回報率完全獨立，是為了舒適度而調校，而非為了延遲。
• 瞄準品質來自感應器準確度、表面、握持方式與練習。一隻 1000Hz 但感應器帶有平滑化或角度校正的滑鼠，瞄準表現會比一隻感應器乾淨俐落的 500Hz 滑鼠還差。

這兩者都不會因為回報率規格而變好，而廠商正從這種模糊中獲利。

驗證你實際拿到的是什麼

「設定的回報率」與「實際送出的回報率」確實可能不一致，但瀏覽器無法直接讀取硬體的回報率：滑鼠事件會受到瀏覽器合併、主執行緒排程與作業系統輸入處理的影響，因此網頁端的計時無法證明真實的 USB 回報間隔。要可靠量測，請使用能讀取 USB 層級資料的專用原生工具，或滑鼠廠商的軟體。像我們的滑鼠測試器這樣的瀏覽器工具能貢獻的，是粗略的模式檢查——記錄到的更新之間出現異常長且一致的間隔，可能暗示連線路徑（共用集線器、前置面板接頭或品質不佳的線材）正在限制傳輸，值得用原生工具進一步確認。請先直接接到主機板後方的 USB 3.0 連接埠重測一次，再下「滑鼠有問題」的結論。

建議的預設值

• 有線電競滑鼠： 1000Hz。安全、標準、沒有實質缺點。
• 無線滑鼠： 現代 2.4GHz 接收器支援 1000Hz，請依優先順序選擇：要最大反應速度就選 1000Hz，要續航就選 500Hz——對多數使用者而言手感差異無感，而 500Hz 省下的電力貨真價實。
• 配備高更新率螢幕與高幀率的競技主機： 試試 1000Hz 到 2000Hz，誠實評估你是否真的察覺出差異。如果沒有，就調回來，把處理器餘裕討回來。
• 其他人，包括所有生產力用途： 500Hz 完全足夠。這個問題不值得再花心思。

USB 在協定層面如何處理滑鼠回報

USB 裝置透過端點（endpoint）與主機溝通，每個端點都會被設定為特定的傳輸類型。滑鼠使用中斷傳輸（interrupt transfer），其輪詢間隔由主控制器按設定的頻率排定——主機保留這些時槽，但實際交付在系統負載下仍可能抖動；裝置則以手上現有的資料回應。時間粒度取決於 USB 速度：Full-Speed 裝置（滑鼠的典型）以 1 毫秒的幀為單位排程，而 High-Speed 裝置則使用 125 微秒的微幀。因此，設定為 1000Hz 的滑鼠在 Full-Speed 連線上會取得 1 毫秒的時槽；端點間隔的確切語意因 Full-Speed 與 High-Speed 而異，實際的回報節奏也取決於裝置的描述符如何宣告其間隔。滑鼠把一份回報封包放進該時槽，內容包含當前的位置位移、按鍵狀態，以及任何額外的感應器資料。

回報封包本身是由裝置的 HID 描述符（HID descriptor）定義的，它宣告了滑鼠所送出資料的結構與大小。一份標準回報包含一個按鍵狀態位元組、一個 X 位移、一個 Y 位移，以及選配的滾輪與額外軸向資料。總承載量很小——通常是 8 到 16 位元組——這意味著頻寬幾乎從來都不是限制。真正的限制是時序：主機多久排定一次傳輸、裝置能多快把它填滿、以及作業系統的輸入堆疊能多快處理它。

在作業系統層面，每一筆收到的回報都會觸發一次中斷，這道中斷會穿過 USB 驅動程式堆疊、HID 類別驅動程式，最終抵達輸入子系統，由其更新游標位置或把事件轉交給前景應用程式。作業系統並不會簡單地把每一筆回報都轉交給遊戲引擎；它會依自身的輸入處理設計進行批次、合併或處理，這意味著並非每一筆回報都必然會影響到某個渲染幀。

這種協定層面的理解釐清了幾個重點。第一，回報率是 USB 端點設定的屬性，而不是滑鼠感應器的屬性——感應器可以按自己的頻率獨立取樣。第二，相容的主機與裝置可以在設定的間隔排定回報，但實際節奏仍取決於描述符、韌體、連線與作業系統排程。第三，處理成本是真實存在的，而且在極端回報率下會持續累積——這就是為什麼 8000Hz 滑鼠可能降低遊戲效能而非提升它。規格描述的是一種排程節奏，而不是感知改善的保證；線材與螢幕之間的每一層，各自帶有回報率無法解決的延遲。

還有個更細膩的地方：USB 控制器的排程並非完全確定。主控制器管理著共用同一條匯流排的多個裝置，同一控制器上的其他流量仍可能引入抖動（jitter）——也就是每次傳輸實際發生時刻的微小變異。在設定良好的系統上，若滑鼠使用專屬控制器，這種抖動可忽略不計，通常在 0.1 毫秒以下。但若滑鼠與外接儲存、擷取卡這類高頻寬裝置共用一個控制器，排程競爭就可能產生偶發延遲——就絕對值而言很小，卻能用精密儀器量測出來。這也是競技玩家常把滑鼠接到主機板廠商建議的特定 USB 連接埠、而非就近隨手找一個埠的原因之一。

要理解回報率在整體延遲鏈中的位置，不妨追蹤一次滑鼠移動，看它如何從實體表面一路走過每個階段、直到螢幕上的游標變化。每個階段都會貢獻時間，而回報只是其中之一。

感應器取樣。 滑鼠內的光學感應器會以很高的內部頻率——通常是每秒 12,000 到 16,000 幀——拍攝表面影像，並比較連續幀來計算移動量。這個過程完全在感應器內部進行，按自己的頻率運作，與 USB 回報率無關。感應器產生一份位置位移後，交給滑鼠的微控制器。

微控制器處理。 MCU 收到感應器位移後，套用任何已設定的處理——例如角度校正、平滑化或加速——再組裝成一份 USB 回報封包。這個階段會加上一點點但非零的延遲，在設計良好的韌體上通常不到 1 毫秒，但在帶有大量 DSP 處理的裝置上可能更長。

USB 傳輸。 這就是由回報率主導的階段。在 1000Hz 下，組裝好的回報會等待下一次排定的中斷傳輸，也就是每 1 毫秒一次。平均而言，回報會等上這個間隔的一半——0.5 毫秒——才被傳送到主機。在 500Hz 下，平均等待時間翻倍為 1 毫秒。

作業系統輸入堆疊。 主機收到回報後，依序透過 USB 驅動程式、HID 類別驅動程式與輸入子系統處理。游標位置在作業系統合成器（compositor）中更新，原始輸入事件則被轉交給遊戲。依作業系統、驅動程式版本與系統負載而定，這個階段約需 1 到 3 毫秒。

遊戲引擎處理。 遊戲收到輸入事件後，套用自己的輸入處理邏輯（可能包括靈敏度縮放、原始輸入與緩衝輸入的選擇、以及依賴幀率的取樣），並把移動併入下一個渲染幀。如果遊戲以 60fps 運作，每幀需時 16.7 毫秒，這意味著移動必須等到下一幀渲染完成並呈現在螢幕上之後才能出現。

顯示呈現。 渲染好的幀傳送到螢幕，螢幕依自己的更新間隔呈現。在 144Hz 下，幀抵達螢幕輸入緩衝區後，會在 6.9 毫秒內出現在畫面上。

把各階段的典型時間加總：感應器（0.25ms）＋MCU（0.5ms）＋1000Hz 的 USB（0.5ms）＋作業系統（2ms）＋60fps 的遊戲（平均 8.3ms）＋144Hz 的顯示（3.5ms）＝約 15 毫秒。USB 回報階段約佔總量的 3%。把它降到 500Hz 會多加 0.5 毫秒，總量變成 15.5 毫秒。這正是為什麼 500Hz 與 1000Hz 之間量測到的差異始終低於 1 毫秒——其餘 96% 的管線完全沒變。這些數字僅供參考；實際數值取決於特定的作業系統、驅動程式、遊戲與螢幕。

這段話的含意不是「回報率無關緊要」，而是「它是最後才該優化的環節」。如果你的遊戲跑在 60fps，把幀率提高到 144fps 平均能消除約 4.9 毫秒的幀等待（16.7ms/2 減 6.9ms/2）——大約是把回報率翻倍所能省下的 10 倍。如果你的螢幕是 60Hz，升級到 144Hz 平均能消除約 4.9 毫秒（16.7ms/2 減 6.9ms/2）。確切數字取決於你量測的是平均等待、完整幀時間還是端對端延遲，因此請把它們視為參考值，而非放諸四海皆準。這兩種改動還都會帶來回報率調整所無法比擬的動態清晰度提升。唯有當幀率與更新率都已經很高時，回報率在剩餘延遲中的占比才會相對變大，而即便如此，就絕對值而言它仍然很小。

需要記住的數字

1000Hz 確實比 500Hz 好，正好好了 1 毫秒——這是一項真實、卻幾乎永遠看不見的改善。請先把優化心力放在螢幕更新率與穩定幀率上，因為那些環節帶來的延遲大上一個數量級；之後再考慮回報率是否改變了任何你能感知到的東西。在整條管線的其他部分能消化那種解析度之前，請把 8000Hz 當作規格表上的成就，而非有感升級。