如何防抖和节流javascript_它们能优化哪些性能问题【教程】_技术教程

防抖适合用户操作有收尾意图的场景，如搜索输入完成、窗口调整结束，核心是等待停顿后执行最后一次；节流适用于需稳定频率响应的场景，如滚动计算可视区、拖拽更新位置，本质是固定间隔最多执行一次。

防抖和节流不是“万能优化”，它们只在特定场景下有效——比如高频事件（resize、scroll、input）触发的重复计算或请求。用错地方反而引入延迟或丢失逻辑，先明确这点再动手。

防抖（debounce）适合什么场景？

用户操作有“收尾意图”的时候才执行，比如搜索框输入完成、窗口调整结束。核心是「等停顿」。

debounce 会忽略中间所有调用，只保留最后一次触发后的延迟执行
典型错误：给按钮点击加防抖——用户点一下没反应，体验崩坏
常见漏掉的参数：immediate 控制是否立即执行第一次（比如希望输入即查，但后续停顿才查），不传默认为 false
示例中别直接写 setTimeout 闭包嵌套三层，用函数工厂更清晰：

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

节流（throttle）什么时候必须用？

需要“稳定频率”响应，而不是“等停顿”。比如滚动时实时计算可视区域、拖拽时更新位置、Canvas 动画帧同步。

节流本质是「固定间隔最多执行一次」，有两种主流实现：定时器版（setTimeout）和时间戳版（Date.now()）
定时器版可能丢帧（最后一次触发若没到间隔就被清空，就不执行了）；时间戳版更可靠，但首次调用立刻执行
别把节流当防抖用：比如给 input 加节流，用户快速打字会明显卡顿或漏字符
注意 this 和参数透传——箭头函数会丢失 this，必须用 fn.apply(this, args)

为什么原生事件监听里直接写逻辑会出问题？

浏览器对 scroll 或 resize 的触发频率极高（每秒几十次），每次触发都执行 DOM 查询、计算、重排，CPU 占用飙升，页面直接卡死。

没包装的 addEventListener('scroll', handleScroll) 是性能黑洞，尤其在移动端
Chrome DevTools 的 Performance 面板里能看到大量 Layout 和 Recalculate Style 堆积，这就是典型信号
防抖/节流只是第一层——如果 handleScroll 本身还在反复查 offsetTop 或 getBoundingClientRect()，照样慢
进阶做法：配合 IntersectionObserver 替代 scroll 监听可见性，或用 requestIdleCallback 把非关键计算延后