先搞懂「防抖（debounce）是啥？

作者：Terry2025.07.07来源：Web前端之家浏览：788评论:0

做前端开发时，你肯定遇到过这样的场景：搜索框输入时要实时联想结果，页面滚动时要加载更多内容，窗口大小变化时要重新计算布局……但这些操作会触发高频事件，频繁执行函数容易把页面搞卡，这时候“防抖（debounce）”和“节流（throttle）”就是常用的性能优化手段，可很多人刚接触时会犯懵：这俩到底有啥区别？啥时候用哪个？今天咱们用大白话把这事掰扯清楚。

防抖的核心逻辑可以总结成 **“延迟执行 + 重复触发就重置延迟”**，先给你举个生活里的例子：电梯关门，电梯门默认会延迟几秒关闭，要是这期间有人按“开门”键，电梯就会重新计时——之前的延迟作废，等新的延迟时间到了再关门。

对应到JavaScript里，假设我们要优化搜索框的实时联想功能，用户输入时，input事件会疯狂触发，要是每次输入都发请求，接口压力大不说，用户还没输完关键词，联想结果就来回跳，体验也差，这时候用防抖，就能让请求“等用户停笔了再发”。

看段简单的防抖代码逻辑：

function debounce(fn, delay) {
  let timer; // 用闭包保存定时器
  return function(...args) {
    clearTimeout(timer); // 每次触发都清掉之前的定时器
    timer = setTimeout(() => {
      fn.apply(this, args); // 延迟后执行目标函数
    }, delay);
  };
}
// 绑定到搜索框的input事件
const input = document.querySelector('input');
input.addEventListener('input', debounce(() => {
  console.log('发请求获取联想结果');
}, 500));

逻辑很直观：用户每次输入（触发事件），都会把之前没执行的定时器清掉，重新设一个500ms的延迟，只有当用户停止输入500ms后，定时器才会触发请求，要是用户在500ms内又输入了，之前的延迟直接作废，重新等500ms——这就是“重复触发重置延迟”的关键。

再看「节流（throttle）」的逻辑是啥？

节流的核心是 “固定间隔执行，不管触发多少次”，还是举生活例子：水龙头滴水，要是把水龙头调成“节流模式”，它会固定每秒滴一滴水——不管你怎么拧水龙头（频繁触发），每秒最多只滴一滴。

在前端里，最典型的场景是页面滚动加载，滚动事件触发特别频繁，要是每次滚动都去检测“是否到页面底部”，浏览器得疯狂计算，页面很容易卡，用节流就能控制：不管滚动多快，每隔固定时间（比如300ms）才执行一次检测，既保证功能，又减少性能消耗。

节流的代码实现有两种常见思路：时间戳版和定时器版，先看时间戳版：

function throttle(fn, interval) {
  let lastTime = 0; // 记录上次执行的时间
  return function(...args) {
    const now = Date.now(); // 当前时间
    if (now - lastTime > interval) { // 时间差超过间隔
      fn.apply(this, args); // 执行函数
      lastTime = now; // 更新上次执行时间
    }
  };
}
// 绑定到滚动事件
window.addEventListener('scroll', throttle(() => {
  console.log('检测是否到页面底部');
}, 300));

逻辑是：每次触发事件时，对比“现在时间”和“上次执行时间”的差，如果差大于设定的间隔（300ms），就执行函数，并更新上次执行时间，这样不管滚动多频繁，300ms内最多执行一次。

再看定时器版的节流（适合需要“最后一次触发也执行”的场景）：

function throttle(fn, interval) {
  let timer; // 保存定时器
  return function(...args) {
    if (!timer) { // 没有定时器时才设置
      timer = setTimeout(() => {
        fn.apply(this, args);
        timer = null; // 执行完清空定时器
      }, interval);
    }
  };
}

这种写法的特点是：第一次触发事件时，会先设个定时器，间隔时间到了才执行函数，如果在间隔内又触发事件，因为定时器还在（timer不为空），所以不会重复设定时器——直到上次的定时器执行完，才会允许下一次执行。

防抖和节流的核心区别在哪？

光看概念可能还是迷糊，咱们从执行时机、适用场景、内部逻辑三个维度拆分对比：

执行时机：“等停了再做” vs “到点就做”

防抖是“等用户停止触发后，延迟执行”，比如搜索框，用户连续输入时，防抖会一直“压着”请求不发，直到用户停笔（一段时间没输入），才执行请求。

节流是“不管用户有没有继续触发，到固定时间就执行”，比如滚动加载，不管用户是快速滑还是慢慢滑，节流会每隔300ms执行一次检测——哪怕用户还在滚动，到点了就执行。

适用场景：“防重复触发” vs “控执行频率”

防抖更适合“只需要响应最后一次触发”的场景：

搜索联想：用户连续输入时，中间的输入状态没必要发请求，只需要最后一次输入的关键词对应的结果。
窗口resize：调整窗口大小时，resize事件会疯狂触发，用防抖只在用户停止调整后，执行一次布局更新（比如重新计算元素位置），避免频繁计算。
按钮防重复点击：比如登录按钮，用户手快点了多次，防抖可以让“提交请求”延迟执行，确保只有最后一次点击生效（配合后端接口幂等性更稳）。

节流更适合“高频事件中，必须按固定频率执行”的场景：

滚动加载：页面滚动时，必须定期检测是否到了底部，用节流控制检测频率，避免性能爆炸。
鼠标跟随效果：比如鼠标移动时，元素要跟着鼠标走（mousemove事件），用节流减少计算次数，避免页面卡顿。
游戏技能CD：比如游戏里放技能有冷却时间，不管玩家点多快，节流能保证“冷却时间到了才能放技能”。

内部逻辑：“重置定时器” vs “时间间隔判断”

防抖的核心是“每次触发都清空之前的定时器，重新延迟”，所以代码里一定会有 clearTimeout(timer) 和 setTimeout 的组合，靠定时器的“重置”来实现延迟逻辑。

节流的核心是“判断是否到执行时间/是否有定时器”，时间戳版靠对比“现在时间”和“上次执行时间”的差；定时器版靠“定时器是否存在”来限制执行频率——本质是控制函数在固定间隔内只执行一次。

实际开发怎么选？举具体例子对比

光说理论太虚，咱们拿“搜索框联想”“滚动加载”“按钮提交”三个常见场景，看防抖和节流怎么选：

例子1：搜索框实时联想

需求：用户输入关键词，实时显示联想结果。

用防抖：用户输入时，每次输入都会延迟请求（比如500ms），如果用户在500ms内又输入了，之前的延迟直接作废，重新等500ms，只有用户停止输入500ms后，才发请求，这样既减少了请求次数，又能拿到用户最终想搜的关键词。
用节流：如果设300ms间隔，用户快速输入时，可能300ms内会发多次请求（比如用户1秒内输入了3次，节流会触发3次请求），但用户要的是“最后一次输入”的结果，中间的请求完全是多余的，反而浪费资源，所以搜索联想优先选防抖。

例子2：页面滚动加载更多

需求：用户滚动页面到底部时，自动加载下一页内容。

用节流：滚动事件触发极频繁，用节流设300ms间隔，不管用户怎么滚，300ms内只检测一次“是否到了底部”，这样既保证了检测的及时性（用户滚动过程中就能触发加载），又不会因为频繁检测把页面搞卡。
用防抖：只有用户停止滚动后才检测，这会导致用户还没滚到想要的位置（比如手指还在屏幕上滑），就停止检测了，体验很糟，所以滚动加载优先选节流。

例子3：按钮点击提交表单

需求：防止用户快速点击按钮，导致重复提交请求。

用防抖：设300ms延迟，用户快速点多次，只有最后一次点击后300ms才执行提交，这样能保证“用户停止点击后，只发一次请求”。
用节流：设300ms间隔，第一次点击后，300ms内不能再点，这种方式更像“冷却时间”，用户点了一次后，必须等300ms才能点第二次。

这时候选哪个？看产品需求：如果希望“用户不管点多快，只认最后一次”，用防抖；如果希望“固定时间内只能点一次”，用节流，比如电商下单按钮，更怕重复提交，用节流（配合后端接口幂等）更稳；如果是搜索按钮，用户可能快速点多次换关键词，用防抖更灵活。

代码实现时的细节差异

除了核心逻辑，防抖和节流在代码细节上也有区别，这些细节会影响实际效果：

防抖：“立即执行”变种

有些场景需要“用户第一次触发就执行，之后触发才延迟”，比如搜索框，用户第一次输入就想立刻发请求（怕延迟太久体验差），之后输入才延迟，这时候可以给防抖加个“立即执行”参数：

function debounce(fn, delay, immediate) {
  let timer;
  return function(...args) {
    clearTimeout(timer);
    if (immediate && !timer) { // 第一次触发时，immediate为true且timer为空（还没设过定时器）
      fn.apply(this, args);
    }
    timer = setTimeout(() => {
      timer = null; // 延迟后清空timer，允许下一次立即执行
    }, delay);
  };
}

节流：“ trailing 执行”变种

定时器版的节流有个特点：停止触发后，还会执行最后一次，比如用户快速滚动页面，触发了10次滚动事件，节流设300ms间隔，最后一次触发后，定时器到时间还会执行一次检测，这在某些场景下很有用（比如必须确保最后一次触发也被处理），而时间戳版的节流不会有这个“ trailing 执行”，因为它靠时间差判断，停止触发后不会再执行。

所以实际开发中，要根据场景选节流的实现方式：需要最后一次执行，用定时器版；不需要，用时间戳版。