17370845950

防抖和节流是工具而非自动优化方案；用错场景或参数会恶化体验。debounce需正确处理immediate逻辑并透传参数；throttle应据场景选leading/trailing；框架中需稳定函数引用；实时性高、必响应的场景禁用。

防抖和节流不能“自动优化体验”，它们只是工具；用错场景、参数不合理，反而会让交互变卡顿或失灵。

debounce 函数怎么写才不丢事件？

常见错误是只在定时器里 clearTimeout，却没处理「最后一次调用后立即执行」的逻辑。比如搜索框输入，用户敲完回车，你得确保这次请求发出去，而不是被清掉。

• 必须把 immediate 参数作为开关：为 true 时首次调用立刻执行，后续触发重置定时器；为 false 时等停顿后再执行
• 返回的函数要能接收任意参数，并透传给原函数（用 ...args）
• 每次调用都要存一份新的 timeoutId，避免闭包捕获旧值导致清除失败

function debounce(func, wait, immediate = false) {
  let timeoutId;
  return function(...args) {
    const later = () => {
      timeoutId = null;
      if (!immediate) func(...args);
    };
    const callNow = immediate && !timeoutId;
    clearTimeout(timeoutId);
    timeoutId = setTimeout(later, wait);
    if (callNow) func(...args);
  };
}

throttle 的 leading / trailing 怎么选？

滚动监听、鼠标拖拽这类高频连续动作，leading: true 能保证“动起来就有响应”；但如果你只关心最终位置（比如 resize 后重排版），trailing: true 更合适——否则窗口快速拉伸时会反复触发，而最后一次可能被截断。

• leading 控制是否在第一次触发时立即执行（默认 true）
• trailing 控制是否在停止触发后补一次执行（默认 true）
• 两者都为 false 就退化成普通定时器，基本没意义
• 注意：如果 leading 和 trailing 都为 true，且间隔刚好卡在边界上，可能同一周期内执行两次

Vue/React 里直接用 Lodash 的 debounce 有坑吗？

有。Lodash 的 debounce 返回的是新函数，但 React 的 useCallback 或 Vue 的 watch 依赖数组里如果没稳定引用，会导致重复绑定或内存泄漏。

• React 中不要在 render 里直接调用 debounce(fn, 300)，应提前定义并 memo 化：const debouncedFn = useCallback(debounce(handler, 300), [handler])
• Vue 3 的 watch 若监听响应式对象，且回调里用了防抖函数，需确保该函数是同一个引用，否则每次 watch 触发都会新建一个防抖实例
• Lodash 的 debounce 不支持取消（cancel）时清空 pending 状态，自定义实现更可控

什么时候不该用防抖或节流？

实时性要求高的场景，比如游戏按键、手写笔迹、语音输入状态更新——这些需要每一帧或每次事件都响应，加防抖/节流等于主动丢帧。

• 表单校验：输入中实时提示可以节流（如每 500ms 校一次），但失焦（blur）必须立刻校验，不能防抖
• 接口请求：防抖适合搜索建议，但提交按钮点击必须立刻发请求，防抖会导致用户点了没反应
• 动画控制：用 requestAnimationFrame 替代节流，它天然对齐屏幕刷新率，比基于 setTimeout 的节流更精准

最常被忽略的一点：防抖节流解决的是「频次问题」，不是「性能问题」。如果函数本身执行慢（比如遍历万级数组），光防抖没用，得先优化函数内部逻辑。