JS 节流与防抖的区别及适用场景对比

图示：JS 防抖（Debounce）与节流（Throttle）的核心控制意图对比

在前端交互开发中，诸如 scroll 页面滚动、resize 窗口尺寸调整、mousemove 鼠标移动以及 input 实时输入等事件，都属于每秒可能被触发几十甚至上百次的高频事件。如果在这些事件的回调中直接执行复杂的 DOM 节点计算或发起异步网络请求，浏览器的主线程就会被高频任务占满，造成画面掉帧卡顿甚至请求雪崩。节流与防抖正是解决该类高频触发问题的两套核心控制方案。

一、核心定义：一句话区分防抖与节流

理解两者的最直接方式，是观察它们对待“连续密集动作”时的裁决方式：

• 防抖 (Debounce)：等你说完我再做（静默生效）。
  如果在设定的时间间隔内事件再次被触发，则清空旧计时并重新开始计时。只有在用户停止操作、界面维持了指定时长的“静默”之后，目标函数才会真正执行一次。
• 节流 (Throttle)：按固定节奏均匀放行（控频放行）。
  无论用户触发得多频繁、多剧烈，在指定的时间周期内只允许目标函数执行一次。它像水龙头下的节流阀，即使水压再大，水流也是一滴一滴匀速规律地滴落。

二、触发机制与执行时序对比

为了直观展现两者在时间维度上的执行节奏差异，我们设定时间等待阈值为 T = 200ms。当下游连续传入多个密集的事件脉冲时，原始调用流、防抖执行流与节流执行流的表现如下图所示：

图 1：高频事件触发与防抖/节流响应时序对比

从时序图中可以清晰观察到两个关键事实：

1. 在第 1 轮高频触发区中，原始事件被连续触发了 6 次。防抖（默认的后置 trailing 模式）在每一次触发时都会刷新计时，直到最后一次触发并等待完整的静默窗口后，才执行了 1 次；而节流在首发立即响应后，按固定周期再次放行，全程匀速执行了 3 次。
2. 防抖关注的是“动作的终点”，节流关注的是“过程的节奏”。防抖彻底省去了中间态，节流则在约束上限的前提下保留了中间态的持续反馈。

三、执行逻辑推导流程图

在算法实现层面，防抖与节流内部维护的状态变量和分支逻辑各有侧重：

图 2：防抖与节流执行流程与算法推导

防抖的核心是“重置”：每次事件到来，若发现前序还有未触发的定时器引用 timer，立刻通过 clearTimeout(timer) 将其撤销，重新拉起新的延时等待；
节流的核心是“限频”：每次事件到来，对比当前时间戳 now 与上一次成功执行的时间戳 previous。只有当流逝的时间差超过指定的阈值间隔，才允许放行，并刷新记录点。

四、原生 JavaScript 纯手写实现

在生产环境开发中，手写实现必须处理好两大核心细节：保持原本函数的 this 上下文指向，以及完整透传事件对象 event 或参数列表。

1. 基础防抖函数 (Debounce) 实现

/**
 * 原生防抖实现
 * @param {Function} fn 需要包装的目标函数
 * @param {number} delay 等待静默的延迟毫秒数 (默认 200ms)
 * @returns {Function} 具有防抖能力的包装函数
 */
function debounce(fn, delay = 200) {
  let timer = null;

  return function (...args) {
    // 缓存当前调用的 this 上下文 (例如绑定的 DOM 节点)
    const context = this;

    // 如果上一次倒计时尚未结束，直接清除，重新计时
    if (timer) {
      clearTimeout(timer);
    }

    timer = setTimeout(() => {
      fn.apply(context, args);
      timer = null;
    }, delay);
  };
}

2. 基础节流函数 (Throttle) 实现

节流常见的有时间戳法（首次立即执行）与定时器法（延后执行）。在工程实践中，推荐优先采用时间戳法，能够提供良好的即时反馈感：

/**
 * 原生节流实现 (时间戳版：首发立即执行)
 * @param {Function} fn 需要包装的目标函数
 * @param {number} interval 固定的执行周期毫秒数 (默认 200ms)
 * @returns {Function} 具有节流能力的包装函数
 */
function throttle(fn, interval = 200) {
  let previous = 0;

  return function (...args) {
    const now = Date.now();
    const context = this;

    // 如果距离上次执行的时间已经大于等于间隔设定值，立即放行
    if (now - previous >= interval) {
      previous = now;
      fn.apply(context, args);
    }
  };
}

五、多维度技术指标对比矩阵

为了让架构评估与技术选型更加明确，我们将防抖与节流在各个关键维度上的差异汇总如下：

图 3：防抖与节流多维技术指标对比矩阵

六、常见业务场景选型指南与决策

在日常业务开发中，究竟该选防抖还是节流？只需回答一个核心问题：“在用户高频触发的过程中，需不需要持续、平滑的即时反馈？”

图 4：实际业务开发场景选型决策树

1. 典型防抖场景 (不需要中间过程，只要最终稳定输入)

• 搜索框输入联想 (Search Autocomplete)： 用户快速输入拼音或单词“javascript”时，有连续多次 input 触发。若每次击键都请求后端接口，不仅消耗服务器资源，而且早发出的请求可能后到达引起异步竞态冲突。使用防抖，等用户停笔 300ms 后再发起检索最为合理。
• 浏览器窗口重置大小 (Window Resize)： 窗口调整尺寸过程中会抛出大量 resize 事件。图表重绘 (ECharts/Canvas) 属于重型计算，通常在用户拖动停止后重新计算并自适应渲染一次即可。
• 表单内容输入格式校验： 用户在填写手机号或邮箱时，不需要每敲一个字符就红字报错“格式不正确”，等停顿 500ms 后校验更符合交互直觉。

2. 典型节流场景 (需要持续感知过程，但需控制频率上限)

• 页面滚动与无限加载 (Window Scroll / Infinite Scroll)： 监听滚动条位置以实现“图片懒加载”或“触底加载更多列表数据”。如果使用防抖，用户在持续快速下滑时界面将完全不加载任何新内容，直到手停下来才加载，体验极其卡顿生硬；而使用节流（如 150ms 触发一次），下滑过程中能够平稳且规律地检测距离底部的距离。
• DOM 元素拖拽或鼠标轨迹绘制 (Mousemove / Drag)： 拖拽悬浮窗或 Canvas 画板涂鸦时，若完全不用限流，DOM 更新频率将超过屏幕刷新率造成丢帧；若用防抖，元素在拖动中途直接“定身”，松开鼠标瞬间瞬间瞬移。节流可以在 16ms~50ms 之间平滑过渡，既跟手又不过载。
• 按钮连击与防重复提交： 某些提交或点赞按钮在移动端容易被快速连按多次。通过节流（搭配 leading 立即执行模式），第一次点击立即发起处理，接下来的 1 秒内屏蔽任何重复点击。

七、工程落地的注意事项

1. 注意 Arrow Function 导致 this 丢失： 在给防抖或节流包装的回调函数编写业务逻辑时，如果需要访问绑定事件的 DOM 对象（如 this.value），请使用普通函数形式 function(e) { ... }，避免在内层强行写箭头函数导致 this 被绑定到外层词法环境。
2. 组件销毁时的内存泄漏排查： 在 React 的 useEffect 或 Vue 的 onUnmounted 生命周期中，如果组件被卸载，必须提供 cancel() 方法清除尚未执行的闭包定时器，防止组件卸载后回调函数仍在后台触发导致的内存泄漏与警告。
3. 成熟类库的选择： 在大型团队协作或复杂边界要求（如同时需要 leading 首发执行与 trailing 尾部兜底）时，建议直接引入 lodash.debounce 与 lodash.throttle，其内部经过了完善的边缘时钟偏差校验与单体测试覆盖。