前端性能优化里有两个词，几乎每个做过交互的人都绕不开：节流（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 执行后下一轮是否还能立即触发。参数组合的行为差异建议用表格记牢：
| leading | trailing | 首次触发 | 连续触发中 | 停止后 |
|---|---|---|---|---|
| true | true | 立即执行 | 按间隔执行 | 补执行末次 |
| true | false | 立即执行 | 按间隔执行 | 不补 |
| false | true | 延迟执行 | 按间隔执行 | 补执行末次 |
| false | false | 延迟执行 | 按间隔执行 | 不补 |
实际项目里我一般默认leading: true, trailing: true，兼顾即时反馈和末次状态。只有明确知道末次执行会引发问题（比如重复提交）时才关掉 trailing。
3. 放进真实场景：参数怎么定，坑怎么避
3.1 间隔时间的计算依据
delay和interval填多少，不是拍脑袋。核心依据是人眼可感知的流畅阈值和业务容忍度。
滚动、拖拽这类跟手操作，间隔建议 16ms 左右（约一帧），再低没有意义，因为屏幕也就刷新那么快；如果回调较重，可以放宽到 50ms，人眼对 50ms 内的延迟基本无感。搜索联想输入，防抖延迟通常 300ms 到 500ms，300ms 是“打字停顿”的常见感知边界，低于 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”的争论。
