防抖是连续触发时只执行最后一次，每次新触发就清空并重设定时器；常用于搜索输入等场景，需注意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（严格模式）。
立即学习“Java免费学习笔记（深入）”；
- 错误写法：
input.addEventListener('input', debounce(handleInput, 300))——handleInput内部的this丢失 - 正确写法：用
bind显式绑定，或改用箭头函数包装（但要确保不破坏防抖逻辑） - React 中更常见问题：函数组件内定义的
debounce每次渲染都新建，导致事件监听器不断重绑 —— 必须用useCallback+useRef缓存
性能优化效果取决于场景，不是“加了就快”
防抖本身有轻微开销（定时器管理、闭包维持），但它省掉的是后续昂贵操作 —— 比如频繁触发 fetch 请求、重排重绘（reflow）、或复杂计算。是否值得加，要看被防抖的函数成本有多高。
- 适合：搜索建议请求、
resize触发布局计算、表单校验（需等用户停顿） - 不适合：鼠标移动轨迹记录、实时协作光标位置同步（需要低延迟反馈）
- 注意：
delay设太小（如 50ms）几乎无效；设太大（如 1000ms）会让交互显得迟钝 —— 通常 200–400ms 是较平衡的选择
真正容易被忽略的是：防抖函数一旦创建，就持有了对外部作用域的引用。如果它被长期挂载（比如全局事件监听），又没调用 cancel，就可能引发内存泄漏。
