做前端這些年被問得最多的一類問題不是框架怎么選而是“這個滾動監(jiān)聽卡得要死怎么辦”“輸入框每敲一個字就發(fā)一次請求后端同事快盯上我了”。這類問題的答案基本都落在防抖Debounce和節(jié)流Throttle這兩個詞上而它們又恰恰是前端性能優(yōu)化里投入產(chǎn)出比最高的兩個小工具。這兩個概念人人都聽過面試也能背出定義但真正在業(yè)務里寫對、用對、調對的人并不多——我見過太多把防抖寫成節(jié)流、把節(jié)流寫成“限流”、甚至在組件卸載之后還留著定時器默默執(zhí)行的代碼。這篇就把這兩個高頻回調控制手段徹底拆開講它們各自解決什么問題實現(xiàn)上有哪些坑等待參數(shù)該怎么算在搜索聯(lián)想、滾動加載、按鈕防連點、埋點上報這些真實場景里怎么落地以及怎么和請求競態(tài)、組件生命周期配合起來。無論你是剛入門還是已經(jīng)寫了兩三年業(yè)務代碼看完至少能做到一件事拿到一個高頻觸發(fā)的場景幾秒鐘判斷出該用哪個并且能徒手寫出來不用翻文檔。1. 先把這兩個概念釘死在場景里1.1 高頻回調為什么會把頁面拖垮瀏覽器的主線程只有一個JS 執(zhí)行、樣式計算、布局、繪制全都排在它后面。一個mousemove在高刷新率設備上一秒能觸發(fā)一百多次一次scroll在慣性滾動里也能輕松跑到六十次以上input事件更是每敲一個字符就來一次?；卣{本身不貴貴的是回調里通常干的事讀scrollTop、讀offsetHeight、改 DOM、發(fā)請求。這里有個很多人不知道的細節(jié)在同一個任務里先寫 DOM 樣式、緊接著讀布局屬性瀏覽器為了給你正確的值會被迫立刻做一次同步布局計算。你寫十次讀十次就是十次強制重排。滾動監(jiān)聽里那種“讀位置—改樣式—再讀位置”的寫法掉幀就是這么來的?；卣{頻率越高這種強制同步布局發(fā)生得越密集最終表現(xiàn)就是滾動條拖不動、手指劃下去畫面發(fā)黏。請求風暴是另一個后果。搜索框如果不做控制用戶輸入“性能優(yōu)化”四個字會發(fā)出四次請求而且這四次請求的返回順序完全不保證——第一字的結果可能最后才回來把正確結果覆蓋掉用戶看到的聯(lián)想詞永遠慢半拍。埋點上報更典型滾動一次上報一次一篇文章從頭滑到尾能給你刷出幾百條日志服務端和客戶端兩邊都難受。所以這類優(yōu)化的核心思路從來不是“讓回調跑得更快”而是降低回調的執(zhí)行次數(shù)同時不破壞用戶感知的連續(xù)性。這就是防抖和節(jié)流要解決的問題兩者都在做“降頻”但降頻的規(guī)則完全不同。1.2 防抖與節(jié)流的本質差異等安靜 vs 按節(jié)拍我習慣用一個生活場景來講這個區(qū)別。防抖像電梯門只要還有人往里走門就一直重新計時直到徹底沒人了才關上。節(jié)流像地鐵班次不管站臺上擠了多少人車都是按固定間隔發(fā)一班人再多也不會連發(fā)三趟。落到代碼上防抖關注的是“事件停止后的那一刻”它把一串密集觸發(fā)合并成最后一次或第一次執(zhí)行節(jié)流關注的是“固定時間窗口內(nèi)的第一次”它保證在一段時間內(nèi)最多執(zhí)行一次中間密集的觸發(fā)直接被丟掉。這個差異決定了它們的適用面維度防抖 Debounce節(jié)流 Throttle觸發(fā)時機停止觸發(fā) wait 毫秒后執(zhí)行每隔 wait 毫秒最多執(zhí)行一次中間觸發(fā)不斷重置計時全部丟棄窗口內(nèi)的觸發(fā)被丟棄窗口末尾恢復執(zhí)行次數(shù)一整串操作通常只執(zhí)行 1 次與持續(xù)時長成正比持續(xù)越久執(zhí)行越多典型場景搜索聯(lián)想、表單校驗、窗口 resize 結束、自動保存滾動加載、滾動視差、拖拽跟隨、埋點上報、按鈕防連點用戶感知有“等一下才響應”的延遲感響應是連續(xù)的只是頻率被壓低了判斷標準其實一句話就夠了你關心的是“最終結果”還是“過程中的連續(xù)反饋”搜索框里用戶敲完才是最終結果用防抖滾動視差每挪一段就要更新一次位置用節(jié)流。搞混這兩個代碼不一定報錯但體驗會很別扭——比如把滾動加載寫成防抖用戶必須停下來不動才會觸發(fā)加載滑到底部一直滑就一直不加載這個 bug 我見過不止一次。2. 防抖從“最后一次才執(zhí)行”到可配置的工程實現(xiàn)2.1 最小可用版本與它的三個致命缺陷網(wǎng)上流傳最廣的防抖實現(xiàn)大概長這樣function debounce(fn, wait) { let timer null; return function (...args) { clearTimeout(timer); timer setTimeout(() fn.apply(this, args), wait); }; }十行不到日常用也確實能跑。但它有三個問題在真實項目里遲早會咬你一口。第一個是this指向。注意上面內(nèi)層用的是箭頭函數(shù)箭頭函數(shù)沒有自己的this它捕獲的是debounce執(zhí)行時的外層this。如果你把返回的函數(shù)掛到某個對象上或者用在類方法里this就丟了。穩(wěn)妥的寫法是內(nèi)層用普通函數(shù)同時在入口處把this存下來const ctx this;然后fn.apply(ctx, args)。第二個是返回值。有些場景需要拿到被包裝函數(shù)的返回值比如表單校驗函數(shù)返回布爾值防抖之后返回值直接變成undefined調用方拿到就懵了。這個得靠debounced.flush()或者閉包里緩存result來解決。第三個最要命沒法取消。組件卸載了、路由切走了、彈窗關閉了那個setTimeout還在隊列里時間一到照樣執(zhí)行執(zhí)行時訪問的 DOM 早就沒了輕則報Cannot read properties of null重則往已經(jīng)銷毀的 store 里寫臟數(shù)據(jù)。所以一個能上生產(chǎn)的防抖必須帶cancel。注意定時器句柄一定要在外層閉包里聲明成let不要掛到返回函數(shù)的屬性上也不要用全局變量。每個防抖實例的定時器是獨立的混用會出現(xiàn)“A 的輸入把 B 的計時清掉”這種極其難查的串擾。2.2 立即執(zhí)行、取消與返回值把核心邏輯拆開下面這版是我在項目里用了很久的實現(xiàn)支持首次立即執(zhí)行l(wèi)eading、末次執(zhí)行trailing、手動取消cancel和立即結算flushfunction debounce(fn, wait 300, options {}) { let timer null; let lastArgs null; let lastThis null; let result; const { leading false, trailing true } options; function invoke() { if (!lastArgs) return result; result fn.apply(lastThis, lastArgs); lastArgs null; lastThis null; return result; } function debounced(...args) { lastArgs args; lastThis this; // 判斷這次是不是“新一串事件”的第一次 const callNow leading !timer; if (timer) clearTimeout(timer); timer setTimeout(() { timer null; if (trailing) invoke(); }, wait); if (callNow) invoke(); return result; } debounced.cancel function () { if (timer) clearTimeout(timer); timer null; lastArgs null; lastThis null; }; debounced.flush function () { if (timer) { clearTimeout(timer); timer null; invoke(); } return result; }; return debounced; }關鍵點拆一下。callNow的判斷依據(jù)是!timer而不是別的標志位——因為在一次完整的靜默周期內(nèi)timer從setTimeout開始一直到回調里置空這段時間它都是真值只有靜默wait毫秒之后才會變回null。用timer本身當狀態(tài)能避免引入額外變量導致的時序錯亂。invoke里做了if (!lastArgs) return result;的空判斷。這是因為flush()和定時器回調都可能調用invoke如果上一次已經(jīng)執(zhí)行完把lastArgs清空了再進來就會用空參數(shù)調用一次原函數(shù)典型的“在控制臺看到一條參數(shù)為 undefined 的多余日志”。加了這個判斷flush在已經(jīng)執(zhí)行過的情況下就只返回緩存結果不會重復觸發(fā)。leading: true的場景很具體按鈕防連點。用戶點第一下要立刻有反饋不能等 300 毫秒后面連續(xù)的狂點全部丟掉同時trailing: false避免最后一次點擊又補一個請求導致用戶只點了一次卻發(fā)了兩個請求。而搜索聯(lián)想恰恰相反要leading: false, trailing: true等用戶停手再發(fā)。這兩個組合別搞反。2.3 參數(shù)計算wait 到底該給多少wait給多少沒有標準答案但有幾個錨點可以參照。前端有個公認的感知閾值100 毫秒以內(nèi)的延遲用戶基本無感超過 200 毫秒開始有“卡了一下”的感覺超過 1 秒就是明確的等待。所以防抖參數(shù)要在這個區(qū)間里找平衡。搜索聯(lián)想這類場景我一般給250 到 350 毫秒。低于 200 毫秒打字快的人還是會連發(fā)兩三個請求起不到合并效果高于 400 毫秒用戶敲完字會明顯感覺聯(lián)想詞“慢半拍”尤其是千兆寬帶下請求本身只要 30 毫秒返回延遲全壓在防抖上了。300 是個能兼顧兩邊的中間值。表單實時校驗、自動保存草稿這類可以放寬到500 到 800 毫秒。這些操作用戶本來就不期待即時反饋而且頻繁請求后端做唯一性校驗服務壓力更敏感。窗口resize結束時重排圖表給150 到 200 毫秒就夠因為反復拖拽瀏覽器窗口邊框時觸發(fā)間隔本來就比較松散。這里還有個更容易被忽略的點輸入法組合輸入。用中文拼音打字input事件會在輸入拼音字母階段就觸發(fā)比如敲“xingneng”會連續(xù)觸發(fā)七八次但此時輸入框里的值是拼音串而不是漢字。如果只做防抖不做保護用戶拼音還沒選完就可能發(fā)出去一個?qxing的請求。解決辦法一行就夠let composing false; input.addEventListener(compositionstart, () { composing true; }); input.addEventListener(compositionend, (e) { composing false; handleInput(e.target.value); // 組合結束后立刻走一次 }); input.addEventListener(input, (e) { if (composing) return; // 組合期間直接忽略 handleInput(e.target.value); });handleInput本身就是防抖過的函數(shù)compositionend那一腳相當于提前結算把拼音階段攢下的等待直接兌現(xiàn)用戶選完字的瞬間就能看到聯(lián)想結果體驗比純防抖更順。3. 節(jié)流時間戳與定時器兩條路的取舍3.1 兩種基礎寫法差在哪節(jié)流的基礎實現(xiàn)有兩條路差異全在“首次”和“末次”上很多人背了代碼卻沒搞清楚這個差異用錯了才發(fā)現(xiàn)問題。時間戳版本function throttleByTimestamp(fn, wait) { let last 0; return function (...args) { const now Date.now(); if (now - last wait) { last now; fn.apply(this, args); } }; }它的特點是last初始為0第一次調用時now - last是一個巨大的正數(shù)必然滿足條件所以首次立即執(zhí)行但最后一次觸發(fā)如果落在當前時間窗口內(nèi)就會被丟棄末次不執(zhí)行。滾動視差用這個沒問題頁面停下來時位置本身就是對的。但如果是“滾動到底部加載更多”末次不執(zhí)行就意味著用戶正好停在一個卡在閾值附近的臨界位置永遠不觸發(fā)加載得再動一下手指才行。定時器版本function throttleByTimer(fn, wait) { let timer null; return function (...args) { if (timer) return; timer setTimeout(() { timer null; fn.apply(this, args); }, wait); }; }它反過來首次要等wait毫秒才執(zhí)行首延遲但最后一次一定會執(zhí)行末次必觸發(fā)。寬表格橫向滾動同步表頭、拖拽結束后保存位置這類場景末次觸發(fā)很關鍵否則最后一下拖拽就丟了。3.2 組合版首尾都要觸發(fā)實際業(yè)務里最常需要的是“首次立即給反饋 末次補齊”把兩條路縫起來function throttle(fn, wait 200) { let lastTime 0; let timer null; function throttled(...args) { const now Date.now(); const remaining wait - (now - lastTime); if (remaining 0) { // 時間窗口已過立刻執(zhí)行并清掉可能存在的補丁定時器 if (timer) { clearTimeout(timer); timer null; } lastTime now; fn.apply(this, args); return; } // 窗口內(nèi)不再執(zhí)行但保證末次一定被補上 if (!timer) { timer setTimeout(() { timer null; lastTime Date.now(); fn.apply(this, args); }, remaining); } } throttled.cancel function () { if (timer) clearTimeout(timer); timer null; lastTime 0; }; return throttled; }代碼里有三個細節(jié)值得說。remaining 0那個分支除了執(zhí)行函數(shù)還必須清掉已有的timer——因為窗口已經(jīng)過了手動執(zhí)行完如果再讓老定時器到期補一發(fā)就變成執(zhí)行兩次了。if (!timer)這個守衛(wèi)保證一個窗口內(nèi)最多只掛一個補丁定時器不會越積越多。lastTime在補丁定時器里要重新賦值否則下一輪判斷的基準還是舊的窗口會算短。cancel里把lastTime重置成0是個小技巧。如果組件銷毀后又被復用比如彈窗關了再打開重置時間基準能讓第一次觸發(fā)立刻執(zhí)行而不是被上次遺留的時間戳卡住半個窗口。3.3 交給渲染節(jié)奏的 rAF 型節(jié)流如果節(jié)流的回調里要改樣式、做動畫、算位置那又有一層更貼合瀏覽器的選擇用requestAnimationFrame代替定時器。原因很簡單瀏覽器一幀是 16.7 毫秒60Hz 屏幕你用setTimeout(fn, 10)去做滾動動畫觸發(fā)點可能落在兩幀之間瀏覽器得把這次的樣式變更攢到下一幀才渲染反而多一次無效計算。rAF 會保證回調在渲染之前的那一幀執(zhí)行改動和繪制對齊function rafThrottle(fn) { let ticking false; return function (...args) { if (ticking) return; ticking true; const ctx this; requestAnimationFrame(() { fn.apply(ctx, args); ticking false; }); }; }它的“節(jié)拍”不再是固定毫秒數(shù)而是跟著顯示器刷新率走60Hz 屏幕相當于 16.7 毫秒一次120Hz 屏幕就是 8.3 毫秒一次。滾動監(jiān)聽里讀位置算聯(lián)動、吸頂頭部切換、視差位移我基本都用這版。有個坑要避開頁面切到后臺標簽頁時 rAF 會被暫停ticking會一直卡在true回來之后所有觸發(fā)都被吞掉。所以如果這東西用在長生命周期的全局監(jiān)聽上最好在visibilitychange里重置一下狀態(tài)或者在頁面重新可見時手動跑一次。4. 落地到真實業(yè)務三個高頻場景的完整方案4.1 搜索聯(lián)想防抖只是第一步競態(tài)才是真問題搜索框是防抖最常見的落地場景但只加防抖是半成品。真實情況是用戶先輸入“性能”請求 A 發(fā)出300 毫秒后又輸入“性能優(yōu)化”請求 B 發(fā)出。A 在路上堵了一下B 先回來了頁面渲染 B 的結果兩秒后 A 回來了把頁面覆蓋成“性能”的聯(lián)想詞。用戶看著輸入框里明晃晃的“性能優(yōu)化”四個字下面顯示的是“性能”的結果體驗直接崩掉。處理方案是在防抖之外加一層請求序號校驗let seq 0; const fetchSuggest debounce(async (keyword) { if (!keyword.trim()) { renderSuggest([]); return; } const current seq; try { const res await fetch(/api/suggest?q${encodeURIComponent(keyword)}); const data await res.json(); // 回來的時候如果序號已經(jīng)變了說明這是個過期請求直接丟棄 if (current ! seq) return; renderSuggest(data.list); } catch (err) { if (current ! seq) return; renderSuggest([]); } }, 300);seq是個單調遞增的計數(shù)器每次發(fā)請求前自增并記下當前值回來時對比。這個思路比AbortController取消請求更省事因為用戶手速快的時候可能一瞬間發(fā)出好幾個請求挨個取消反而麻煩序號校驗的好處是請求照發(fā)只是結果按最新的一版渲染。當然如果你更在意省流量用AbortController把上一個請求掐掉也行注意abort會拋出一個AbortError得在 catch 里把它單獨過濾掉別讓它進全局錯誤上報。還有個體驗細節(jié)請求發(fā)出到回來這段時間最好給輸入框一個pending狀態(tài)比如輸入框右側轉個圈。否則用戶敲完字之后 300 毫秒防抖 200 毫秒接口耗時加起來半秒多沒反應會以為頁面卡了。4.2 滾動加載與埋點上報節(jié)流 單調時鐘滾動加載更多的判斷邏輯本身不復雜核心是算距離底部的距離const onScroll throttle(() { const doc document.documentElement; const distanceToBottom doc.scrollHeight - window.innerHeight - window.scrollY; if (distanceToBottom 300 !loading hasMore) { loadNextPage(); } }, 200); window.addEventListener(scroll, onScroll, { passive: true });這里有兩個容易被忽略的點。一是{ passive: true }它告訴瀏覽器這個監(jiān)聽器不會調用preventDefault()瀏覽器就不用等回調執(zhí)行完再滾動滾動流暢度能明顯提升。滾動、觸摸移動這類高頻事件都該加上不加的話控制臺會給你一條“consider marking your touch and wheel event listeners as passive”的提示。二是閾值別給太小。distanceToBottom 300意思是距離底部還有 300 像素就開始加載這個余量是為了讓下一頁在用戶真正滑到底之前就準備好。如果你只有一個可滾動容器比如固定高度overflow: auto的列表window.scrollY就用錯了得換成容器的scrollTopinnerHeight換成clientHeightscrollHeight換成容器的scrollHeight。這種混用是滾動加載不觸發(fā)的頭號原因我在好幾個項目里都遇到過。埋點上報的場景對時鐘更敏感。用Date.now()計算時間差有個隱患用戶在系統(tǒng)設置里手動改了時間或者設備自動校時跳了一下Date.now()會出現(xiàn)跳變可能算出一個負的間隔導致節(jié)流失效now - lastTime變成負數(shù)永遠滿足條件或者長時間不觸發(fā)。穩(wěn)妥做法是用單調時鐘performance.now()const report throttle(() { const payload { page: currentPath, depth: Math.round((window.scrollY / document.body.scrollHeight) * 100), ts: Date.now() // 上報時用真實時間戳用于統(tǒng)計 }; navigator.sendBeacon(/api/track, JSON.stringify(payload)); }, 800);注意分工控制頻率用performance.now()業(yè)務時間戳用Date.now()。兩者各司其職別混著用。另外上報優(yōu)先用navigator.sendBeacon它在頁面卸載時也能把數(shù)據(jù)遞出去比在unload里發(fā)同步請求靠譜得多。4.3 按鈕防連點與框架里的清理按鈕防連點用leading: true, trailing: false的防抖最合適const handleSubmit debounce(async (formData) { submitting.value true; try { await api.submit(formData); toast.success(提交成功); } finally { submitting.value false; } }, 800, { leading: true, trailing: false });wait給 800 毫秒是為了覆蓋一次接口往返。這里有個前提防抖只能攔住“快速連點”攔不住“網(wǎng)絡慢導致的重復提交”。如果接口要跑 3 秒用戶在 800 毫秒后再點一次照樣能發(fā)出去第二個請求。所以服務端冪等唯一請求號和按鈕禁用狀態(tài)這兩層還是得有防抖只是第一道最廉價的防線別指望它解決全部問題?？蚣芾镒铌P鍵的一步是清理。防抖和節(jié)流返回的函數(shù)都持有閉包和定時器組件卸載時必須調cancel否則定時器到期執(zhí)行時訪問的響應式變量、DOM 引用都已經(jīng)失效。React 里的封裝function useDebouncedCallback(fn, wait, deps []) { const fnRef useRef(fn); fnRef.current fn; const debounced useMemo( () debounce((...args) fnRef.current(...args), wait), [wait] ); useEffect(() () debounced.cancel(), [debounced]); return debounced; }fnRef這層是關鍵。如果把fn直接塞進useMemo的依賴里父組件每次重渲染傳進來的新函數(shù)都會讓防抖實例重建定時器全部作廢防抖直接失效——這是 React 里防抖“看起來沒生效”的最常見原因。用 ref 存最新的函數(shù)、useMemo只依賴wait實例就穩(wěn)定了。Vue 3 里思路一致用onUnmounted收拾import { onUnmounted } from vue; export function useThrottle(fn, wait 200) { const throttled throttle(fn, wait); onUnmounted(() throttled.cancel()); return throttled; }順帶提一句全局監(jiān)聽的問題。如果監(jiān)聽器掛在window上組件卸載時不僅要removeEventListener還要先cancel掉包裝函數(shù)。因為addEventListener存的是包裝后的引用你remove的時候必須傳同一個引用很多人重新寫了一遍throttle(fn)去移除函數(shù)引用不同根本刪不掉監(jiān)聽器就這么一直掛著內(nèi)存和 CPU 一起漏。5. 選型、排查與踩坑速查5.1 一張決策表把選型問題關掉每次有人問我“這個該用防抖還是節(jié)流”我基本按下面這張表回答實測覆蓋了九成場景場景選擇建議參數(shù)關鍵配置搜索框聯(lián)想防抖250-350mstrailing: true配合請求序號表單實時校驗防抖400-600ms監(jiān)聽compositionstart/end自動保存草稿防抖800-1500ms卸載前flush一次窗口 resize 重排防抖150-200ms圖表類可配合ResizeObserver滾動加載更多節(jié)流150-250mspassive: true注意容器內(nèi)滾動的取值埋點曝光上報節(jié)流500-1000ms用performance.now()計時拖拽跟隨、視差rAF 節(jié)流跟幀走后臺切回時重置狀態(tài)按鈕防連點防抖500-800msleading: true, trailing: false輸入框字符數(shù)統(tǒng)計不處理—純計算本身開銷可忽略最后一行值得單獨說。不是所有高頻事件都需要包裝像字符數(shù)統(tǒng)計、簡單的class切換開銷就是幾微秒硬套一層防抖反而增加復雜度還可能引入時序 bug。優(yōu)化的第一步永遠是先測量performance面板跑一遍看看到底是哪個函數(shù)吃掉了時間別憑感覺上工具。5.2 常見問題排查表下面這些是我和同事在真實項目里踩過的、并且反復出現(xiàn)在代碼評審里的問題按現(xiàn)象整理成速查表現(xiàn)象大概率原因處理方式防抖“完全沒生效”每次觸發(fā)都執(zhí)行包裝函數(shù)在每次渲染時被重建React 用useMemo固定實例Vue 放setup頂層報Cannot read properties of null組件卸載后定時器仍執(zhí)行卸載時調用cancel()節(jié)流第一次不觸發(fā)用了定時器版本首延遲換組合版或把lastTime初始化為-Infinity節(jié)流最后一次不觸發(fā)用了時間戳版本加補丁定時器或改組合版中文輸入發(fā)了一堆拼音請求沒處理組合輸入compositionstart/end攔截聯(lián)想詞和輸入框內(nèi)容對不上請求競態(tài)序號校驗或AbortController滾動加載在某個位置永遠不觸發(fā)只判斷了一次或取值對象用錯換容器滾動取值加distanceToBottom打印摘除監(jiān)聽后仍在執(zhí)行移除的引用和添加的不一致保存包裝函數(shù)引用先cancel再remove頁面切后臺回來動畫不同步rAF 暫停導致ticking卡死visibilitychange里重置5.3 我踩過的三個坑第一個坑是防抖和節(jié)流混著用。早年做一個橫滑表頭的表格我給scroll套了防抖本意是等用戶停下滑動再同步表頭位置。結果用戶習慣一路滑到底全程表頭紋絲不動停下來的瞬間“啪”地跳過去觀感極差。后來換成 rAF 節(jié)流滾動過程中表頭平滑跟隨問題當場就沒了。這件事讓我記住凡是需要過程連續(xù)反饋的一律節(jié)流只有需要等最終結果的才用防抖。第二個坑是參數(shù)給得太激進。有個項目的搜索聯(lián)想防抖給了 500 毫秒測試環(huán)境一切正常上了生產(chǎn)用戶反饋“輸入框像死了一樣”。排查半天發(fā)現(xiàn)接口在弱網(wǎng)下平均要 400 毫秒才返回500 400 將近一秒用戶早就不耐煩了。后來把防抖降到 250 毫秒同時在輸入框里加了個 loading 指示觀感立刻好轉。防抖的延遲和接口耗時是疊加的不是取最大值算參數(shù)時必須把這段一起算進去。第三個坑是過度包裝。有個列表頁給每一行的一個小圖標都套了獨立的節(jié)流函數(shù)五百行就是五百個閉包加五百個定時器句柄頁面一進去內(nèi)存就蹭蹭漲。這種情況正確的做法是把包裝函數(shù)提到列表外面所有行共享一個節(jié)流實例靠event.target或者行索引區(qū)分數(shù)據(jù)來源。包裝函數(shù)是有成本的別在循環(huán)或者列表項里現(xiàn)造。后續(xù)如果還想往深里走可以看看這兩個方向一是把防抖節(jié)流和IntersectionObserver、ResizeObserver結合起來能用觀察者解決的問題就不用監(jiān)聽事件瀏覽器原生幫你算比 JS 里反復讀布局便宜得多二是去翻一翻成熟工具庫的源碼實現(xiàn)對比一下它們在leading/trailing邊界、maxWait這類擴展參數(shù)上的處理方式會發(fā)現(xiàn)自己手寫版本里漏掉的很多邊角情況。我個人在實際操作中的體會是這兩個函數(shù)加起來不到五十行但真正吃透它帶來的收益遠超五十行代碼本身——它訓練的是對“事件頻率、執(zhí)行時機、生命周期”這三件事的敏感度這種敏感度放到任何性能優(yōu)化場景里都用得上。