防抖和节流是针对不同高频事件场景的互斥策略：防抖适用于“等用户彻底停手再执行”（如搜索、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 绘图、滚动视差、游戏按键响应——这些依赖中间状态的场景，throttle 或 requestAnimationFrame 才合适。

性能影响差异：

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

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

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

注意点：

• 它不适用于需要精确毫秒控制的逻辑（如音频同步）
• 需手动管理 rafId 并在组件卸载/事件解绑时 cancelAnimationFrame
• 不能直接替代防抖——它不解决“停手后才执行”的需求

let rafId = null;
function animateScroll() {
  // 更新 UI
  rafId = requestAnimationFrame(animateScroll);
}
// 启动
rafId = requestAnimationFrame(animateScroll);
// 清理
if (rafId) cancelAnimationFrame(rafId);

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