前端性能优化里有两个词几乎每个做过交互的人都绕不开节流Throttle和防抖Debounce。它们不是某个框架的专属 API也不是什么高深算法本质就是两段几十行的高阶函数却能把滚动、输入、拖拽、窗口缩放这些高频触发的事件从“疯狂轰炸”压成“按需响应”。我见过太多页面滚动监听里直接读布局属性、输入框每敲一个字符就发一次请求结果主线程被拖垮、接口被打爆用户还以为是网络卡。这两个工具就是干这个的把不该那么频繁执行的回调用时间窗口管起来。不管你是刚接触事件监听的初学者还是已经写过不少业务代码、想搞清楚“为什么我写的防抖在组件里失效了”的中级开发者这篇都会有用。我会从设计思路讲到参数计算从手写实现讲到框架里的坑尽量把每个“为什么这么选”都掰开说清楚。1. 先搞清楚这两个东西到底在解决什么问题1.1 高频事件的本质触发频率远超处理能力浏览器里有一类事件触发频率由用户的手速和硬件决定而不是由你的代码决定。scroll、mousemove、touchmove、resize、input、wheel都属于这一类。以scroll为例现代浏览器在滚动时通常以接近屏幕刷新率的节奏派发事件60Hz 屏幕意味着每秒最多 60 次高刷屏能到 120 次甚至更高。mousemove更夸张鼠标移动时每秒上百次派发是常态。问题在于事件回调里做的事往往不便宜。读一次getBoundingClientRect()可能触发强制同步布局发一次网络请求要占用连接和带宽做一次 DOM 批量更新会引发重排重绘。当触发频率是每秒 100 次而单次处理需要 5 毫秒你的主线程就有 50% 的时间被这个回调吃掉剩下的渲染、其他交互全得排队。这就是卡顿的根源——不是代码写得烂是执行次数根本不合理。提示判断一个事件要不要优化看两点——触发是否由连续动作驱动滚动、移动、输入以及回调里是否有布局读取、网络请求、复杂计算。两条都占基本必须上节流或防抖。1.2 节流和防抖的分工一个限速一个等停很多人一开始分不清这俩其实用生活场景一比就清楚了。节流像电梯不管外面排队按了多少次按钮电梯固定每隔一段时间开一次门。你连续滚动页面节流保证回调最多每 N 毫秒执行一次频率被“限速”了但执行不会停。防抖像自动门你一直站在门口进进出出门就一直开着不关等你彻底不动了过一小会儿门才关上。输入框打字就是典型每敲一个字符都重置计时器直到用户停下来超过 N 毫秒才真正触发一次搜索或校验。所以选型逻辑很直接需要过程中持续反馈的用节流滚动进度条、拖拽位置跟随、滚动加载的触发判断只需要最终结果的用防抖搜索联想、表单实时校验、窗口 resize 结束后重算布局。选错了不会报错但体验会怪——比如搜索框用节流用户还没打完就发了一堆请求滚动进度用防抖滚动过程中进度条完全不动松手才跳一下。1.3 一个容易忽略的前提事件本身无法被“减少”这里要纠正一个常见误解。节流和防抖并不能减少浏览器派发事件的次数事件该来还是来scroll依然每秒触发几十上百次。它们做的是在回调入口加一层“闸门”让真正执行业务逻辑的次数变少。理解这一点很重要因为它决定了优化方向如果你的瓶颈是事件派发本身极少见那得换思路如果瓶颈是回调里的重活那这层闸门就够用。也正因为闸门在回调入口所以这两个函数天然适合写成高阶函数——接收一个原函数和间隔时间返回一个包装后的新函数。这个设计让它们可以复用到任何事件上不侵入业务逻辑这也是它们能成为通用工具的根本原因。2. 手写实现从最简版本到生产可用2.1 防抖的最小实现与它的三个缺陷先看最朴素的防抖理解核心机制function debounce(fn, delay) { let timer null; return function (...args) { clearTimeout(timer); timer setTimeout(() { fn.apply(this, args); }, delay); }; }逻辑就三步每次调用先清掉上一个定时器再起一个新的时间到了才执行。核心是clearTimeout不断重置倒计时。这个版本能跑但放到真实项目里立刻暴露三个问题。第一this和参数。上面用了fn.apply(this, args)this指向的是包装函数被调用时的上下文参数也透传了这点没问题。但如果写成箭头函数返回this就会丢这是新手最常踩的坑。第二没有“立即执行”选项。有些场景希望第一次点击立刻响应后续的连点才被合并比如按钮防重复提交。最简版做不到。第三没有cancel方法。组件卸载时定时器还挂着回调可能在组件销毁后执行引发报错或内存泄漏。这在单页应用里非常常见。2.2 防抖的完整版immediate 与 cancel生产可用的防抖要补上立即执行和取消能力function debounce(fn, delay, immediate false) { let timer null; function debounced(...args) { const context this; const callNow immediate !timer; if (timer) clearTimeout(timer); timer setTimeout(() { timer null; if (!immediate) fn.apply(context, args); }, delay); if (callNow) fn.apply(context, args); } debounced.cancel function () { if (timer) clearTimeout(timer); timer null; }; return debounced; }关键点在callNow的判断immediate !timer只有当前没有挂起定时器时才立即执行这样连续触发时只有第一次生效。定时器回调里把timer置空是为了让下一轮触发能重新走立即执行分支。cancel则把定时器清掉并复位状态。注意immediate模式下fn在定时器回调里被跳过了if (!immediate)所以最后一次触发不会补执行。如果你的业务需要“立即执行一次 停止后再执行一次”得单独处理标准防抖不覆盖这种组合需求。2.3 节流的两种实现时间戳与定时器节流有两种经典写法行为略有差异选哪种取决于你要“首次立即”还是“末次补发”。时间戳版首次立即执行末次不补function throttle(fn, interval) { let last 0; return function (...args) { const now Date.now(); if (now - last interval) { last now; fn.apply(this, args); } }; }定时器版首次延迟执行末次会补function throttle(fn, interval) { let timer null; return function (...args) { if (timer) return; const context this; timer setTimeout(() { timer null; fn.apply(context, args); }, interval); }; }两者的差别很实际。时间戳版在滚动开始时立刻响应适合进度条这类需要即时反馈的场景定时器版在停止滚动后会补执行最后一次适合“滚动到底部加载更多”这种不能漏掉末次状态的场景。很多成熟库比如常见的工具库会把两者合并用leading和trailing两个布尔参数控制首末行为本质就是把上面两段逻辑揉在一起。2.4 合并版节流leading 与 trailing 的取舍合并版的核心是记录“上次执行时间”和“是否有挂起定时器”在每次调用时判断该立即执行还是安排延迟function throttle(fn, interval, { leading true, trailing true } {}) { let last 0; let timer null; return function (...args) { const context this; const now Date.now(); if (!last !leading) last now; const remaining interval - (now - last); if (remaining 0 || remaining interval) { if (timer) { clearTimeout(timer); timer null; } last now; fn.apply(context, args); } else if (!timer trailing) { timer setTimeout(() { last leading ? Date.now() : 0; timer null; fn.apply(context, args); }, remaining); } }; }这段代码里remaining interval的判断是防御性的处理系统时间被调整导致now - last异常的情况。last leading ? Date.now() : 0这行决定了 trailing 执行后下一轮是否还能立即触发。参数组合的行为差异建议用表格记牢leadingtrailing首次触发连续触发中停止后truetrue立即执行按间隔执行补执行末次truefalse立即执行按间隔执行不补falsetrue延迟执行按间隔执行补执行末次falsefalse延迟执行按间隔执行不补实际项目里我一般默认leading: true, trailing: true兼顾即时反馈和末次状态。只有明确知道末次执行会引发问题比如重复提交时才关掉 trailing。3. 放进真实场景参数怎么定坑怎么避3.1 间隔时间的计算依据delay和interval填多少不是拍脑袋。核心依据是人眼可感知的流畅阈值和业务容忍度。滚动、拖拽这类跟手操作间隔建议 16ms 左右约一帧再低没有意义因为屏幕也就刷新那么快如果回调较重可以放宽到 50ms人眼对 50ms 内的延迟基本无感。搜索联想输入防抖延迟通常 300ms 到 500ms300ms 是“打字停顿”的常见感知边界低于 200ms 容易在词组输入时误触发高于 500ms 用户会觉得响应迟钝。窗口 resize 重算布局防抖 200ms 到 300ms 比较稳妥因为用户拖动窗口边缘时是连续动作停手后才需要重排。有个简单的估算方法先测单次回调耗时 T再定你能接受的主线程占用比例 P比如 20%那么最小间隔约等于 T / P。比如回调耗时 4ms想控制在 20% 占用间隔就是 20ms。这只是起点最终还得在真机上试。3.2 滚动场景节流 被动监听滚动是最典型的节流场景。除了加节流还有两个配套动作不能少。一是给监听加{ passive: true }告诉浏览器这个监听不会调用preventDefault浏览器就能提前滚动而不等待 JS滚动会更顺。二是回调里避免频繁读布局属性如果必须读把读操作集中到一次或者用requestAnimationFrame包一层。const onScroll throttle(() { const rect container.getBoundingClientRect(); updateIndicator(rect.top); }, 16); window.addEventListener(scroll, onScroll, { passive: true });这里 16ms 配合passive实测在中等复杂度的页面上滚动帧率能稳住。如果页面里有大量图片懒加载判断把判断逻辑也放进节流回调别在原始监听里做。3.3 输入场景防抖 请求取消搜索框的经典组合是防抖加请求竞态处理。防抖解决“打字过程中不发请求”但还有个隐患用户输入 A 触发请求还没回来又输入 B 触发第二个请求如果 A 的响应后到就会覆盖 B 的结果。所以防抖之外还得配一个请求标识或取消机制。let seq 0; const search debounce(async (keyword) { const current seq; const res await fetch(/api/search?q${encodeURIComponent(keyword)}); const data await res.json(); if (current ! seq) return; // 过期响应丢弃 renderResults(data); }, 300);seq自增做版本号响应回来时比对不是最新的一律丢弃。这个模式比直接 abort 请求更简单也不依赖具体请求库的能力。表单实时校验同理防抖 300ms 到 500ms校验结果同样要做版本比对。3.4 框架组件里的生命周期陷阱在组件化框架里用这两个工具最大的坑是包装函数的引用稳定性和卸载清理。如果在组件渲染函数里直接调用debounce(...)每次渲染都会生成一个新函数防抖状态定时器每次都被重置等于完全失效。正确做法是在组件初始化时创建一次并保存引用比如在类组件里放实例属性在函数组件里用useRef或useMemo缓存。卸载时一定要调cancel。定时器是挂在包装函数闭包里的组件销毁后如果定时器还在回调执行时访问已销毁的 DOM 或状态就会报错。我踩过最典型的一次是弹窗关闭后防抖的 resize 回调还在跑去读一个已经不存在的容器尺寸控制台一片红。加上cancel并在卸载钩子里调用问题立刻消失。注意如果包装函数被当作事件监听注册卸载时除了cancel还要用同一个函数引用去removeEventListener。引用不一致会导致监听残留这是比定时器更隐蔽的泄漏源。4. 排查实录那些看起来像 bug 的行为4.1 常见问题速查表实际排查中遇到的问题高度集中整理成表方便对照现象可能原因排查方向处理方式防抖完全不生效每次都执行包装函数在每次渲染时重建检查创建位置是否在渲染路径内用 ref/memo 缓存引用节流首次不触发用了定时器版且 leading 为 false确认实现的首末行为换时间戳版或开 leading停止操作后没有最后一次trailing 被关闭检查参数配置开启 trailing组件卸载后报错定时器未取消检查卸载钩子调用 cancel 并移除监听滚动依然卡顿回调内有强制同步布局用性能面板看 Layout 耗时集中读写、rAF 包裹请求结果错乱响应竞态检查是否有版本比对加序号或取消旧请求4.2 一个隐蔽的坑this 丢失与参数透传用箭头函数写返回的包装函数this会绑定到定义时的词法作用域而不是调用时的上下文。如果原函数依赖this比如类方法里访问实例属性就会拿到undefined或错误对象。解决办法是用普通函数并fn.apply(this, args)或者干脆在调用处用bind固定上下文。参数透传也要注意包装函数必须用...args收集并原样传下去否则事件对象、自定义参数全丢。4.3 性能面板怎么看出优化有没有生效优化完别凭感觉打开性能面板录一段操作。看两个指标主线程上该回调占用的时间块是否变短变稀以及帧率曲线是否平稳。如果回调时间块明显减少但帧率没改善说明瓶颈不在这个回调得往渲染或其他脚本找。另外可以看事件监听的数量和触发次数确认节流确实把执行次数压下来了。我习惯在回调里临时加一个计数器操作前后对比执行次数比看面板更直观。5. 再往深一层什么时候不该用它们这两个工具不是万能药。如果回调本身极轻比如只改一个 class加节流防抖反而增加闭包和定时器开销得不偿失。如果事件触发频率本来就不高比如点击、提交也没必要包一层。还有一种情况是需要每一次事件都精确处理的场景比如绘图板上的笔迹采样漏掉任何一个点都会让线条断裂这时候该考虑的是降低单次处理成本或用专门的高频采样方案而不是粗暴地丢事件。另外现代浏览器有些能力可以替代部分场景。比如滚动驱动的动画用IntersectionObserver判断元素是否进入视口比监听 scroll 再计算位置更高效ResizeObserver处理尺寸变化比监听 window resize 更精准。这些观察者 API 由浏览器内部调度天然避开了高频回调的问题。工具选型的顺序应该是能用观察者 API 解决的优先用解决不了的再上节流防抖。我在实际项目里的体会是这两个函数写起来简单用对地方才值钱。先把事件频率和回调成本摸清楚再决定用哪个、参数填多少比上来就套模板靠谱得多。最后分享一个小技巧把节流和防抖封装成项目内的统一工具默认参数按业务场景预设好比如滚动 16ms、输入 300ms团队里谁用都一致能省掉大量“这个间隔为什么是 250”的争论。