节流是固定频率执行，防抖是停止触发后执行一次；节流适用于需持续响应的场景如滚动监听，防抖适用于只关心最终状态的场景如搜索联想。

节流（throttle）的本质是“固定频率执行”

节流不是阻止函数调用，而是让函数按最大允许频次执行，比如每 200ms 最多执行一次。它适合那些需要持续响应、但又不能太频繁的场景，比如监听页面滚动位置、鼠标拖拽、Canvas 绘图更新。

关键点在于：即使触发非常密集，节流函数内部也会用时间戳或定时器做“节拍控制”，保证执行节奏稳定。

常见错误是把 setTimeout 简单包裹就当节流——那其实是防抖；真正的节流必须区分「立即执行」和「延迟执行」两种模式，且要处理最后一次触发是否遗漏的问题。

典型实现依赖两个状态变量：lastTime（记录上次执行时间）和 timer（用于延迟兜底）。示例如下：

function throttle(fn, delay) {
  let lastTime = 0;
  let timer = null;
  return function(...args) {
    const now = Date.now();
    if (now - lastTime > delay) {
      fn.apply(this, args);
      lastTime = now;
    } else if (!timer) {
      timer = setTimeout(() => {
        fn.apply(this, args);
        lastTime = Date.now();
        timer = null;
      }, delay - (now - lastTime));
    }
  };
}

防抖（debounce）的核心是“等停再执行”

防抖只在事件停止触发后才执行一次，中间所有调用都被丢弃。它适用于搜索框输入联想、窗口大小调整后重排布局、表单校验提交前的最终确认等场景——这些操作不追求实时反馈，只关心“用户真正停下来那一刻”的状态。

容易踩的坑包括：误用防抖处理滚动监听，导致页面滚动中完全没响应；或者没清理上一个 setTimeout，造成多次定时器叠加执行。

防抖实现更轻量，通常只需一个 timer 变量 + clearTimeout 即可，但要注意是否需要支持「立即执行首次调用」（leading edge）：

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

节流与防抖选型的关键判断依据

不是看“哪个更高级”，而是看业务对「响应连续性」和「最终一致性」的要求权重。

• 需要平滑反馈（如 canvas 跟随鼠标画线、滚动时实时计算吸顶状态）→ 选节流
• 只关心结果（如搜索关键词发请求、resize 后重新计算栅格列数）→ 选防抖
• 用户行为本身有自然间隔（如按钮点击）→ 通常不需要二者，用简单开关或 loading 状态更合适
• 高频事件源不可控（如 mousemove 在低性能设备上每秒触发上百次）→ 节流能压降 CPU 占用，防抖可能因始终没“停”而永不执行

现代开发中容易被忽略的细节

原生事件监听器现在支持 { passive: true } 和 { capture: false }，但节流/防抖函数本身不改变事件监听配置。如果用了节流却没设 passive: true，在移动端仍可能触发强制同步布局，导致卡顿。

另外，requestAnimationFrame 是一种特殊的节流形式——它把执行时机交给浏览器渲染帧，比基于时间戳的节流更精准、更节能，但只适用于视觉更新类操作，不能替代通用节流逻辑。

最后提醒：不要在 React 函数组件里每次渲染都新建节流/防抖函数（即不包裹在 useCallback 中），否则会破坏 useEffect 依赖数组稳定性，也可能导致子组件重复绑定事件。