【JS 性能】前端性能優化基石：深入理解防抖（Debounce）與節流（Throttle）

所屬專欄： 《前端小技巧集合：讓你的代碼更優雅高效》
上一篇： 【JS 語法】代碼整潔之道：解構賦值與展開語法的 5 個神仙用法
作者： 碼力無邊

---

? 引言：那一夜，我的頁面因為一次滾動而卡死

嘿，各位熱愛高性能代碼的道友們，我是碼力無邊！

在我們的前端江湖中，高性能是一個永恒的追求。我們不斷優化渲染速度，減少網絡請求，壓縮資源包大小。但是，一個再完美的網站，也可能因為幾個微小的操作，瞬間變得卡頓無比，讓用戶體驗直線下降。

回想一下你可能遇到的場景：

• 用戶在輸入框里快速輸入搜索關鍵詞，每輸入一個字符，你的前端就要觸發一次請求去后端搜索。結果就是：用戶手速越快，頁面越卡，甚至服務器都可能崩潰。
• 用戶在手機上瘋狂滑動頁面（scroll 事件），或者頻繁拖拽一個元素（mousemove 事件）。這些事件在短時間內被觸發了成百上千次，導致頁面頻繁重繪和回流，最終瀏覽器卡頓、崩潰。
• 用戶瘋狂點擊一個按鈕（click 事件），導致重復提交表單，或者發送了多次請求。

這些問題，都是因為我們對高頻事件的處理不當。瀏覽器不會憐憫你的 CPU，它會忠實地、毫秒不差地執行你綁定在事件監聽器上的代碼。

那么，如何馴服這些高頻事件，在保證用戶體驗的前提下，減少代碼的執行次數呢？答案就是我們今天的主角——防抖（Debounce） 和 節流（Throttle）。

它們就像是兩個智能的“門衛”，負責管理進入你代碼主體的事件流。一個負責“延遲放行”，一個負責“限量放行”。掌握它們，你就能讓你的頁面在處理高頻事件時，依然如絲般順滑，性能爆炸！

一、防抖（Debounce）：“你停下來，我就執行”

1.1 核心思想：延遲執行，只執行最后一次

防抖的思路是：當事件連續觸發時，我先不急著執行。我設定一個等待時間，如果在等待時間內事件又被觸發了，我就重新開始計時。只有當事件停止觸發，并且等待時間結束后，我才執行最后一次。

它就像坐地鐵。地鐵關門前，如果有人沖進來，門就會重新打開，等待下一個人沖進來。只有當地鐵站安靜下來一段時間，地鐵才會真正關門開走。

最典型的應用場景：輸入搜索框 (Input/Keyup)

用戶輸入通常是一連串的按鍵，如果我們每按一個鍵都去搜索，會浪費大量資源。我們希望用戶輸入完成后，停頓一下，再去搜索。

1.2 防抖的實現（基礎版）

在 JavaScript 中，我們通常使用 setTimeout 來實現防抖。

/*** 防抖函數 (Debounce)* @param {Function} func - 需要執行的函數* @param {Number} delay - 延遲時間（毫秒）*/
function debounce(func, delay = 500) {let timeoutId = null; // 存儲 setTimeout 的 ID，用于清除計時器return function(...args) {// 1. 在函數執行前，先清除上一次的計時器if (timeoutId) {clearTimeout(timeoutId);}// 2. 重新設置一個新的計時器timeoutId = setTimeout(() => {// 3. 延遲時間到了，執行我們傳入的函數// 注意：使用 apply 或 call 來確保 func 內部的 this 和參數正確傳遞func.apply(this, args);timeoutId = null; // 執行完后可以重置 ID}, delay);};
}

如何使用：

function search(keyword) {console.log(`正在搜索：${keyword}`);// 假設這里是一個實際的后端請求
}// 應用防抖：延遲 300 毫秒
const debounceSearch = debounce(search, 300);// 綁定事件
const searchInput = document.getElementById('search-input');
searchInput.addEventListener('keyup', (event) => {debounceSearch(event.target.value);
});

當你快速敲擊鍵盤時，search() 函數并不會立即執行，只有當你停頓超過 300 毫秒后，它才會執行一次。完美解決了高頻觸發搜索請求的問題。

二、節流（Throttle）：“有節奏地執行”

2.1 核心思想：固定周期執行

節流的思路是：在單位時間內（比如 500 毫秒），不管事件觸發了多少次，我只執行一次。

它就像游戲中的技能冷卻。你按下技能鍵后，技能進入冷卻時間，在這個冷卻時間內，你無論怎么按，技能都無法再次釋放，直到冷卻時間結束。

最典型的應用場景：scroll, resize, mousemove

這些事件通常需要高頻地獲取位置信息或更新布局。但我們不需要每毫秒都執行一次，比如，我們只需要每 200 毫秒執行一次就足夠了。

2.2 節流的實現（基礎版）

節流通常使用“時間戳”或“定時器”來實現。這里我們用“時間戳”方式，它更加簡單直接。

/*** 節流函數 (Throttle)* @param {Function} func - 需要執行的函數* @param {Number} interval - 時間間隔（毫秒）*/
function throttle(func, interval = 500) {let lastTime = 0; // 上次執行的時間戳return function(...args) {const now = Date.now(); // 當前時間戳// 1. 判斷時間間隔是否達到if (now - lastTime > interval) {// 2. 執行函數，并更新上次執行時間lastTime = now;func.apply(this, args);}// 3. 如果時間間隔不夠，不做任何事情};
}

如何使用：

function handleScroll() {console.log('滾動事件觸發，正在處理...');// 假設這里是復雜的 DOM 計算或布局更新
}// 應用節流：每 200 毫秒最多執行一次
const throttledScroll = throttle(handleScroll, 200);// 綁定事件
window.addEventListener('scroll', throttledScroll);

無論用戶滾動速度有多快，handleScroll() 函數都只會在每 200 毫秒的固定頻率下執行，極大地減輕了瀏覽器的計算壓力。

三、防抖 vs 節流：我該用哪個？

特性	防抖 (Debounce)	節流 (Throttle)
執行頻率	連續觸發時，只執行最后一次	連續觸發時，在指定時間間隔內最多執行一次
等待時間	事件停止觸發一段時間后才執行	事件開始觸發后，在固定周期內執行
側重場景	用戶完成操作，再執行	持續操作，需要高頻但有限制地執行
適用場景	搜索輸入、窗口調整大小（Resize）	頁面滾動（Scroll）、鼠標移動（Mousemove）、高頻點擊

總結：

• 防抖（Debounce） 強調的是“只在連續操作結束后，執行一次最終的邏輯”。
• 節流（Throttle） 強調的是“持續操作中，以固定頻率進行執行”。

四、性能考量與注意事項

1. 清除計時器： 如果使用 debounce，并且你的組件在計時器結束前被銷毀了（比如 Vue/React 組件的卸載），你需要在卸載生命周期里調用 clearTimeout(timeoutId)，防止內存泄漏。
2. event 對象問題： 在使用 debounce 或 throttle 封裝的函數中，如果你需要訪問原始的 event 對象，要小心。因為在計時器執行時，event 對象可能已經被回收或重用了。通常的做法是，在外部函數中獲取并傳遞你需要的 event 屬性（如 event.target.value），或者在內部函數的參數列表中獲取。在上面的例子中，我們已經使用了 ...args 和 apply() 來確保參數的傳遞正確性。
3. 庫的選擇： 如果你的項目足夠大，你可以直接使用成熟的工具庫，如 Lodash 的 _.debounce 和 _.throttle。它們的功能更完善，包含了我們今天沒有涉及的“立即執行”等高級選項。但作為前端工程師，掌握其底層原理，在需要時能夠手寫出來，是必須的修煉。

寫在最后：性能優化，從小處著手

防抖和節流，是前端性能優化中最基礎，但也最有效的“心法”之一。它們能讓你在處理高頻事件時，將 CPU 和內存的壓力降到最低，實現絲般順滑的用戶體驗。

掌握它們，你不僅是解決了眼前的問題，更是養成了一種性能優先的編碼習慣。當你下次再看到一個 scroll 或 mousemove 事件時，你的大腦里就會自動響起警鐘：“嘿，是時候請‘門衛’登場了！”

---

專欄預告與互動：

我們已經掌握了 JS 基礎和性能優化的要訣。但一個大型項目，除了代碼本身的邏輯，還需要考慮模塊化、依賴管理等工程化問題。

下一篇，我們將探討 JS 模塊化的進階用法——動態 import() 與代碼分割的藝術。我們將學習如何在需要時才加載代碼，有效縮減首屏加載時間，提升用戶體驗！

碼力無邊的修煉之旅，需要你的持續關注！如果你覺得今天的內容讓你功力大增，請點贊、收藏、關注，助我繼續“飛升”！

今日挑戰： 防抖函數的 timeoutId 變量通常定義在外部作用域。如果你的代碼被打包在模塊中，并且有多個地方調用了 debounce 函數，會有問題嗎？在評論區分享你的分析吧！