javascript防抖与节流是什么_它们如何优化高频事件?

防抖和节流是针对不同高频事件场景的互斥策略:防抖适用于“等用户彻底停手再执行”(如搜索、resize),节流适用于“必须定期响应但不能太密”(如拖拽、滚动);二者需根据是否需要最终状态或过程反馈来选择,且均非性能银弹,须先优化回调函数本身。

防抖和节流不是“选一个就行”的通用方案,而是针对不同高频事件场景的两种互斥策略:防抖适合“等用户彻底停手再执行”,节流适合“必须定期响应但不能太密”。

防抖(debounce):输入框搜索、窗口 resize 后延时执行

典型表现是:连续触发事件时,只在最后一次触发后延迟执行一次。比如用户快速输入 5 个字符,debounce 会忽略前 4 次,只在停止输入 300ms 后调用一次搜索函数。

关键点:

  • setTimeout 必须在每次新触发时 clearTimeout,否则旧定时器仍会执行
  • 首次触发是否立即执行?取决于实现——带 immediate 参数的版本可支持“先执行再等待”,但多数搜索场景不需要
  • 返回的函数需绑定正确 this 和参数,建议用 func.apply(context, args) 而非直接调用
function debounce(func, wait, immediate = false) {
  let timeout;
  return function(...args) {
    const later = () => {
      timeout = null;
      if (!immediate) func.apply(this, args);
    };
    const callNow = immediate && !timeout;
    clearTimeout(timeout);
    timeout = setTimeout(later, wait);
    if (callNow) func.apply(this, args);
  };
}

节流(throttle):鼠标拖拽、滚动监听中控制执行频率

典型表现是:无论事件触发多频繁,函数最多每隔 wait 毫秒执行一次。比如滚动事件每 16ms 触发一次,throttle 可将其限制为每 100ms 最多执行一次。

常见陷阱:

  • 时间戳版节流在首次触发时立即执行,但最后一次触发若不足间隔,则被丢弃;定时器版可保证“最后兜底”,但实现更复杂
  • 不要把 throttle 和 CSS 的 pointer-events: none 混用——后者阻断事件,前者只是降频
  • 若依赖实时坐标(如拖拽位置),节流会导致视觉卡顿,此时应优先考虑 requestAnimationFrame 替代
function throttle(func, wait) {
  let previous = 0;
  return function(...args) {
    const now = Date.now();
    if (now - previous >= wait) {
      func.apply(this, args);
      previous = now;
    }
  };
}

怎么选?看事件是否需要“最终状态”还是“过程反馈”

输入框搜索、表单校验、自动保存——这些操作只关心用户“最终输入了什么”,用 debounce 更合理;而 Canvas 绘图、滚动视差、游戏按键响应——这些依赖中间状态的场景,throttlerequestAnimationFrame 才合适。

性能影响差异:

  • debounce 在高频期完全不执行,内存占用低,但响应有延迟
  • throttle 保持固定节奏,CPU 占用略高,但行为可预测
  • 两者都应避免在回调中做重渲染(如直接操作 DOM),推荐结合 useCallback(React)或手动缓存计算结果

现代替代方案:requestAnimationFrame 有时比两者都合适

当目标是“每帧最多更新一次 UI”,比如监听 scroll 更新 sticky 导航栏位置,requestAnimationFramethrottle(16) 更精准,且天然与浏览器刷新节奏同步。

注意点:

  • 它不适用于需要精确毫秒控制的逻辑(如音频同步)
  • 需手动管理 rafId 并在组件卸载/事件解绑时 cancelAnimationFrame
  • 不能直接替代防抖——它不解决“停手后才执行”的需求
let rafId = null;
function animateScroll() {
  // 更新 UI
  rafId = requestAnimationFrame(animateScroll);
}
// 启动
rafId = requestAnimationFrame(animateScroll);
// 清理
if (rafId) cancelAnimationFrame(rafId);

真正容易被忽略的是:防抖和节流本身不是性能银弹。如果回调函数里做了深克隆、正则全局匹配或未加索引的数组遍历,再怎么节流也救不了。先定位瓶颈,再决定用哪个“流控开关”。