防抖是连续触发时只执行最后一次，每次新触发就清空并重设定时器；常用于搜索输入等场景，需注意this绑定、参数透传、取消机制及内存泄漏风险。

防抖是什么：它不是“延迟执行”，而是“重置定时器”

防抖（debounce）本质是：**连续触发时，只执行最后一次**。它不保证“等 X 毫秒后一定执行”，而是每次新触发就清掉旧的 setTimeout，重新计时。常见于搜索框输入、窗口缩放、按钮连点等场景。

容易误解的点：
• 把防抖和节流（throttle）混为一谈——节流是“固定间隔最多执行一次”，防抖是“最后才执行一次”；
• 认为防抖一定会延迟执行——如果用户只触发一次，且之后不再触发，它会在等待期结束后执行；但如果持续触发，它永远不执行，直到静默期到来。

手写一个可靠防抖函数：注意 this、参数和取消能力

原生没有 debounce，必须自己封装。关键点在于保留原始函数的 this 上下文、透传所有参数，并提供手动取消的接口（比如组件卸载时清理）。

• 不能直接用箭头函数包裹 setTimeout，否则会丢失 this
• 必须用 apply 或展开运算符传递参数，否则 event 等参数会丢失
• 返回的函数应暴露 cancel 方法，避免内存泄漏或意外执行

function debounce(fn, delay) {
  let timer = null;
  const debounced = function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => {
      fn.apply(this, args);
    }, delay);
  };
  debounced.cancel = () => {
    clearTimeout(timer);
    timer = null;
  };
  return debounced;
}

实际使用时最常踩的坑：this 绑定失效和闭包陷阱

在事件监听中直接传入防抖函数，但没绑定 this，会导致内部 fn 执行时 this 指向 window（非严格模式）或 undefined（严格模式）。

• 错误写法：input.addEventListener('input', debounce(handleInput, 300)) —— handleInput 内部的 this 丢失
• 正确写法：用 bind 显式绑定，或改用箭头函数包装（但要确保不破坏防抖逻辑）
• React 中更常见问题：函数组件内定义的 debounce 每次渲染都新建，导致事件监听器不断重绑 —— 必须用 useCallback + useRef 缓存

性能优化效果取决于场景，不是“加了就快”

防抖本身有轻微开销（定时器管理、闭包维持），但它省掉的是后续昂贵操作 —— 比如频繁触发 fetch 请求、重排重绘（reflow）、或复杂计算。是否值得加，要看被防抖的函数成本有多高。

• 适合：搜索建议请求、resize 触发布局计算、表单校验（需等用户停顿）
• 不适合：鼠标移动轨迹记录、实时协作光标位置同步（需要低延迟反馈）
• 注意：delay 设太小（如 50ms）几乎无效；设太大（如 1000ms）会让交互显得迟钝 —— 通常 200–400ms 是较平衡的选择

真正容易被忽略的是：防抖函数一旦创建，就持有了对外部作用域的引用。如果它被长期挂载（比如全局事件监听），又没调用 cancel，就可能引发内存泄漏。