前端性能优化：防抖与节流的原理、区别与实战指南

做前端这些年，防抖和节流这两个词几乎每次面试都会被翻出来问一遍。它不是八股文，而是真正决定页面流畅度和后端压力的两个基础函数。我自己就因为在搜索框里没做防抖处理，接口被用户的高频输入打爆过一次，线上事故复盘时才发现，问题根本不在服务端，就是前端少写了一个函数。从那以后，我但凡遇到高频事件，第一反应就是先问自己：这里该防抖还是该节流？

这篇文章不打算只给两个实现就完事。我会把防抖和节流的原理、区别、实现、边界情况、实战踩坑全部拆开讲透。你如果正准备面试，可以当复习提纲；如果在实际项目里被高频事件困扰，可以直接照抄底下的代码，按自己的场景改参数。

1. 面试必问背后的真实原因：一次高频事件引发的性能事故

先讲我那次事故。当时做一个商城的搜索联想功能，用户每在输入框敲一个字，前端就发一次请求，关键词实时去后端匹配商品名。本地开发环境一切正常，因为开发就我一个人在测。上线后第二天，后端同事就在群里喊：搜索接口 QPS 暴涨，数据库连接池被打满了。我一看监控，某个用户三秒钟内敲了几十个字符，前端就发了四十多次请求，还全是无效的——因为用户打字速度远快于接口返回速度，前面的请求返回时输入框内容已经变了，那些响应全部作废。

这就是典型的没做防抖。用户停止输入后再发请求，需求只需要一次，我却给了它四十次。那次事故之后我把公司所有搜索框、筛选条件、表单校验都排查了一遍，一口气补上了防抖。

1.1 高频事件到底有多频繁

浏览器里的事件触发频率，比很多人想象得夸张得多。鼠标移动 mousemove 在正常移动鼠标时每秒可以触发 30 到 60 次，scroll 滚动事件在快速滑动时每帧都会触发，resize 窗口拖动时更是连续密集触发。如果不加任何处理，这些事件回调里如果做了 DOM 操作、网络请求、复杂计算，页面立马就能感受到卡顿。

有一个前置事实需要先明确：浏览器本身有事件循环机制，但事件的处理顺序并不保证每次触发立即执行回调，也可能合并。真正的问题不在事件循环，而在业务代码——你把一个昂贵的操作（API 请求、重排重绘、大数组遍历）直接挂在了高频事件上，执行次数完全不受控制。

1.2 防抖和节流解决的其实是两类不同的失控

高频事件带来的问题可以分成两种情况：

• 一类是"停止"才有意义的操作：用户输入完才搜、拖拽完才计算位置、连续点击完才提交。这类操作关心的是最后一次。
• 另一类是"持续"才有意义的操作：滚动时加载更多、窗口缩放时重新布局、鼠标移动时跟随效果。这类操作关心的是在执行频率上做限制，不能完全不做，也不能每次都做。

防抖解决第一类，节流解决第二类。这也是它们本质的区别来源——防抖是"等一等，你没动了再做"，节流是"不管你多急，我按自己的节奏来"。

2. 防抖（Debounce）实现拆解：只认最后一次触发

防抖的核心逻辑一句话就能说清楚：事件触发后不立即执行，而是开启一个定时器，等待 delay 毫秒；如果在这个等待期内又触发了事件，就重置定时器重新计时。直到某次触发后过了整整 delay 毫秒都没有新触发，才真正执行回调。

打个比方，防抖像是坐电梯。电梯门快关上的时候，只要还有人赶过来按一下开门键，门就重新打开，继续等下一波人。只有当真的没人再进电梯，电梯才关门运行。

2.1 基础版防抖：一个闭包加一个定时器

javascript复制function debounce(fn, delay = 300) {
  let timer = null;
  return function(...args) {
    const context = this;
    if (timer) {
      clearTimeout(timer);
    }
    timer = setTimeout(() => {
      fn.apply(context, args);
      timer = null;
    }, delay);
  };
}

这个实现里有几个关键点，我逐个说明。

第一，为什么要用闭包？因为 timer 这个变量必须在多次调用之间共享。返回的新函数每次被触发时，都要能拿到上一次设置的定时器并把它清掉。如果 timer 定义在返回函数内部，那每次触发都是全新的变量，防抖就失效了。闭包在这里的作用就是给这个计数器一个稳定的"居住地"。

第二，clearTimeout 之后为什么还要 timer = null？清掉定时器后，timer 变量还残留着旧的时间戳 ID（一个正整数），如果不置空，在需要判断"当前是否有正在等待的定时器"的场景下（比如取消操作），就会出现误判。置空是良好的习惯。

第三，fn.apply(context, args) 这两行不能省。context 保存的是 this，args 保存的是事件对象等参数。如果不处理，回调函数里的 this 会指向错误对象（比如本该是触发事件的 DOM 元素，变成了 window），事件对象 event 也会丢失。后面我会单独讲这个问题。

2.2 实现里的三个关键细节：闭包、this、参数透传

闭包的原理上面说过了，这里重点说 this 和参数。很多人手写防抖时把函数写成这样：

javascript复制function debounce(fn, delay) {
  let timer = null;
  return function() {
    clearTimeout(timer);
    timer = setTimeout(fn, delay); // 看起来简洁，其实有问题
  };
}

问题在哪里？setTimeout(fn, delay) 在延迟到期后会以全局上下文调用 fn，函数的 this 指向 window（严格模式下是 undefined），事件对象也丢了。如果你的回调里用了 this.value 或者 e.target，这里就全错。

所以正确做法是用展开运算符收集参数，再用 apply 显式绑定：

javascript复制return function(...args) {
  const context = this;
  // ...
  timer = setTimeout(() => {
    fn.apply(context, args);
  }, delay);
};

setTimeout 的延迟函数用箭头函数包一层，箭头函数不绑定自己的 this，所以在它内部访问的 context 就是外层作用域保存的那个值。这个组合是手写防抖的标准姿势，面试时能主动讲清楚这两行的作用，比背下整个函数更能加印象分。

2.3 带立即执行参数的升级版：处理"提交按钮"场景

基础的防抖是"延迟执行"，但有一种场景恰恰相反：按钮点击提交，我们希望第一次点击立即生效，只是防止用户在短时间内疯狂重复点击。这时候要的是"立即执行版"防抖，也叫前缘防抖。

javascript复制function debounce(fn, delay = 300, immediate = false) {
  let timer = null;
  return function(...args) {
    const context = this;
    if (timer) {
      clearTimeout(timer);
    }
    if (immediate) {
      const callNow = !timer;
      timer = setTimeout(() => {
        timer = null;
      }, delay);
      if (callNow) {
        fn.apply(context, args);
      }
    } else {
      timer = setTimeout(() => {
        fn.apply(context, args);
        timer = null;
      }, delay);
    }
  };
}

这个版本的逻辑：如果 timer 为空，说明这是连续触发中的第一次，立刻执行回调；然后设置一个定时器，在 delay 毫秒后将 timer 置空。在这个延迟期内，后续触发进来时 timer 还是存在的，所以不会执行、只会不断重置等待时间。等延迟期结束，timer 被置空，下一次触发又会被视为"第一次"，再次立即执行。

用这个函数来限制提交按钮就很合适：第一次点击立即提交，之后在 300ms 内的所有连点都会被忽略，既保住了用户体验，又防住了重复提交。

3. 节流（Throttle）实现拆解：固定频率的节拍器

节流的核心逻辑是：不管事件触发了多少次，回调函数在指定时间间隔内最多执行一次。如果说防抖是"电梯等人上车"，节流就是"地铁按时发车"——到点就走，不管你站台上来了多少人。

实现节流有两种主流思路：时间戳法和定时器法。两种各有特点，我建议两个都掌握，因为面试里经常会追问区别。

3.1 用时间戳实现：直白但边界明显

javascript复制function throttle(fn, interval = 300) {
  let previous = 0;
  return function(...args) {
    const context = this;
    const now = Date.now();
    if (now - previous >= interval) {
      fn.apply(context, args);
      previous = now;
    }
  };
}

原理是记录上一次执行的时间 previous，每次事件触发时用当前时间减去 previous，如果差值大于等于设定的间隔，就执行回调并更新 previous。

这个版本的优点：执行时间点稳定，延迟期内的首次触发会立即执行（因为 previous 初始是 0，now - 0 肯定大于 interval）。用在这种场景最合适：比如排行榜直播的点赞数滚动刷新，用户疯狂点赞时，界面以每 300ms 一次的固定频率更新。

缺点也很明显：最后一次触发如果在间隔时间已经过了、还没到新的执行点时戛然而止，回调不会被补执行。比如用户快速滚动了 700ms 然后停住，interval 是 300ms，那么只会在第 0ms、第 300ms、第 600ms 各执行一次，第 700ms 停止时那次"尾巴"就丢了。有些场景丢尾巴不可接受，比如下拉加载到底部时，最后一次触发的加载逻辑没执行到，用户就看不到新内容。

3.2 用定时器实现：补上尾部的空缺

javascript复制function throttle(fn, interval = 300) {
  let timer = null;
  return function(...args) {
    const context = this;
    if (!timer) {
      timer = setTimeout(() => {
        fn.apply(context, args);
        timer = null;
      }, interval);
    }
  };
}

定时器版的逻辑：如果当前没有正在等待的定时器，就设置一个；延迟到期执行回调并把 timer 置空。在等待期间，所有触发进来看到 timer 存在，直接跳过。

这个版本的特点是：最后一次触发如果在等待期结束后恰好发生，它会新起一个定时器，把"尾巴"补上。但它有个对称的问题——前缘不执行。第一次触发时不会立即执行，而是等满 interval 才执行，会有一段响应延迟感。而且它执行回调的时刻是"每段间隔的末尾"，时间点不够均匀。

3.3 时间戳+定时器组合版：首尾都能执行

实际项目里，我更常用的是组合版：时间戳保证立即响应，定时器保证最后一次不丢。

javascript复制function throttle(fn, interval = 300) {
  let timer = null;
  let previous = 0;
  return function(...args) {
    const context = this;
    const now = Date.now();
    const remaining = interval - (now - previous);
    if (remaining <= 0) {
      if (timer) {
        clearTimeout(timer);
        timer = null;
      }
      fn.apply(context, args);
      previous = now;
    } else if (!timer) {
      timer = setTimeout(() => {
        fn.apply(context, args);
        previous = Date.now();
        timer = null;
      }, remaining);
    }
  };
}

这个函数的行为：事件触发时先算距离上次执行还差多少时间。如果 remaining <= 0，说明间隔已到，立即执行并更新时间戳；如果没到并且没有挂起的定时器，就设置一个定时器，在剩下的时间到达后执行。这样既保证间隔内的首次触发立即响应，又保证停止触发时的最后一次能被补上（通过 else if (!timer) 的分支）。

组合版的理解成本比前两个高一些，但它是实际项目里功能最完整的节流实现。你写代码的时候可以把它当成模板，改改参数直接用。

4. 防抖和节流的核心区别与选型逻辑

很多初学者搞不清这两个概念，是因为它们都在处理"高频触发"，表面看起来很像。但它们的出发点和结果完全不同，理解清楚之后再选型就不会犹豫。

4.1 一张对照表看懂差异

最直观的理解方式：防抖关注的是"停止的时刻"，节流关注的是"执行的频率"。防抖可以把 100 次触发收敛成 1 次，节流可以把 100 次触发收敛成 10 次（按间隔算）。

4.2 按场景选型的判断方法

我在实际项目里一般按三步走：

第一步，问自己"这件事是等用户停下来做，还是边做边持续反馈？"搜索联想、表单实时校验、窗口调整后的重新计算布局，答案都是前者，用防抖。滚动到底部加载更多、鼠标移动的拖拽跟手效果、播放器每秒上报播放进度，答案都是后者，用节流。

第二步，想清楚"漏掉最后一次是否可以接受"。如果不接受，用组合版节流，或者给防抖和节流设置一个最大等待时间（后面讲 lodash 的 maxWait 时细说），保证即使事件一直不停，回调也至少每隔一段时间执行一次。

第三步，看业务对延迟的敏感度。抢购按钮、提交表单这种需要立即反馈且要防重复的操作，用带 immediate 参数的防抖；动画相关的用节流，因为节流的执行频率天然适配浏览器的动画帧节奏。

这一步一步想下来，选型基本不会错。真正出问题的项目，几乎全是在第一步就跳过了判断，直接把回调挂在了事件上。

5. 实战踩坑记录：this 丢失、事件对象、组件卸载与取消

实现本身不难，难的是把防抖节流放进真实项目里运行的时候，各种意想不到的坑一个接一个。这些坑大部分不是函数实现的问题，而是用法的问题。

5.1 丢失的 this 和 event 对象

我在代码评审里见过太多次这个写法：

javascript复制function handleSearch(e) {
  debounce(searchApi, 300)(e);
}

或者直接：

javascript复制const handleSearch = debounce(function(e) {
  console.log(e.target.value); // 报错：Cannot read properties of null
  console.log(this); // window
}, 300);

为什么报错？因为防抖返回的是箭头函数（或者内层函数）包装过的回调，当你把它作为事件监听器时，this 和 event 的传递链路必须从事件绑定处一路透传到最终执行处。如果你在中间某层用了普通函数调用而不是 apply/call，this 就丢了；如果用展开运算符丢掉了参数，event 就没了。

一个容易忽略的细节：debounce 返回的函数本身被调用时，它的 this 是动态绑定的。所以当你把它直接赋给事件监听器时，它内部保存的 context = this 拿到的是正确的 DOM 元素；但如果你把它包在另一个箭头函数里，箭头函数不绑定 this，你也不提前保存，那内部拿到的可能就是 undefined 了。正确用法如下：

javascript复制// 正确：直接把 debounce 返回的函数赋给事件监听器
const input = document.getElementById('search');
input.addEventListener('input', debounce(function(e) {
  searchApi(this.value); // this 指向 input
}, 300));

// 或者显式保存 this
const handleSearch = debounce(function(e) {
  console.log(this.value);
}, 300);
input.addEventListener('input', handleSearch);

5.2 组件卸载后定时器还在执行的隐患

这是单页应用里最隐蔽的坑之一。你在 React 组件的 useEffect 里给窗口绑定了 resize 监听，用了节流，但是在组件卸载时忘了移除监听或者没有取消定时器。结果组件销毁后，定时器到期照样触发回调，回调里访问了已经卸载组件的 DOM 或者 state，轻则报警告，重则内存泄漏。

解决思路有两个：一个是在卸载时正确清理监听，另一个是给防抖节流函数加一个 cancel 方法。

javascript复制function debounce(fn, delay = 300) {
  let timer = null;
  const debounced = function(...args) {
    const context = this;
    if (timer) clearTimeout(timer);
    timer = setTimeout(() => {
      fn.apply(context, args);
      timer = null;
    }, delay);
  };
  debounced.cancel = function() {
    if (timer) clearTimeout(timer);
    timer = null;
  };
  return debounced;
}

React 里配合 useRef 保存返回的函数，卸载时调用 cancel：

javascript复制useEffect(() => {
  const handler = debounce(handleResize, 200);
  window.addEventListener('resize', handler);
  return () => {
    window.removeEventListener('resize', handler);
    handler.cancel(); // 手动取消未执行的定时器
  };
}, []);

5.3 React 和 Vue 里使用防抖节流的正确姿势

React 里最常见的错误是每次渲染都重新生成一个防抖函数。useMemo 或 useRef 用来稳定函数引用，useCallback 包裹回调本身，三个配合起来才能保证防抖稳定工作：

javascript复制const search = useMemo(() => {
  return debounce((keyword) => {
    api.search(keyword);
  }, 300);
}, []);

// 在 onChange 里调用 search

如果这个函数要在多个子组件中传递，外面再套一层 useCallback 保证 props 引用稳定。注意依赖数组是空数组 []，因为防抖函数只需要创建一次，闭包里的 timer 需要长期存活。

Vue 里思路类似，在 setup 中创建防抖函数，卸载时清理。不过 Vue 的 onBeforeUnmount 里别忘了调用 cancel，原理和 React 一致。还有一个 Vue 特有的细节：如果防抖函数包装的 fn 里用到了响应式数据，传参时一定要显式传值，不要靠闭包去捕获响应式对象的引用，否则拿到的可能是旧值。

6. 工具库实现思路与个人心得

手写实现是会了，但真实项目里我更推荐直接用工具库，尤其是 lodash 的 debounce 和 throttle。原因很简单：我在上面讲的边界情况，lodash 全处理了，而且做得比我好得多。

6.1 lodash 的 debounce 和 throttle 到底做了什么

lodash 的 debounce 完整支持一套 options：

• leading：是否在延迟开始前执行（对应我上面说的 immediate）
• trailing：是否在延迟结束后执行
• maxWait：最大等待时间，超过这个时间无论如何都要执行一次

maxWait 这个参数非常重要。它的存在让防抖具备了"节流兜底"能力：如果用户一直在触发事件、从来没有停过，纯防抖会导致回调一直不执行。但设置了 maxWait 之后，回调最多每隔 maxWait 毫秒就会执行一次，既享受了防抖的"等最后一次"，也避免了"永远等不到头"的尴尬。

lodash 的 throttle 其实就是 debounce 设置了 maxWait 和 leading、trailing 都为 true 的特例，源码里直接是：

javascript复制function throttle(func, wait, options) {
  return debounce(func, wait, {
    leading: true,
    trailing: true,
    maxWait: wait
  });
}

所以你可以把节流理解为"带最大等待时间的防抖"。理解这一层之后，再看组合版节流的代码就豁然开朗了。

6.2 手写实现需要掌握到什么程度

面试可以问手写，因为这是一个很好的"看基础"的题目。但实际工作里，我建议优先引入 lodash 这样的成熟库，别重复造轮子。工具库的好处不只是实现完善，连 TypeScript 类型定义、各种奇奇怪怪的边界条件（比如 delay 传负数、fn 抛异常后的状态恢复）都处理好了。

如果你确实需要自定义一个极简版本（比如团队不允许引额外依赖），记住下面这个 checklist 就不会出大问题：

• [x] 返回值：没有 cancel 和 flush 接口的话，无法在组件卸载时清理
• [x] this 和参数是否透传正确
• [x] timer 是否清空置 null
• [x] 是否支持 leading/trailing/maxWait
• [x] 异步场景下（比如回调是 async 函数）是否会因为返回值问题导致异常

最后说一个工具库替代方案：写动画相关的高频处理时，requestAnimationFrame 天然就是一个节流器。它会把回调对齐到浏览器渲染帧，通常每秒执行 60 次，性能和流畅度比固定 setTimeout 节流更好。但注意它不能随意控制间隔（比如我想 300ms 一次就不行），而且页面切到后台时 requestAnimationFrame 会暂停，这点在播放进度上报这类场景要留意。

防抖和节流这两个概念本身不复杂，真正的复杂度全在"用对场景"和"处理边界"上。我自己的经验是：写一个新页面时先不要急着写业务逻辑，先用一秒钟想清楚这个事件回调是否高频、是否昂贵、是否应该延迟执行。这短短一秒钟的思考，节省的是线上事故和半夜被叫醒排查问题的代价。