防抖函数能避免高频触发是因为它通过重置定时器实现“等一等”，仅在最后一次触发后延迟执行；节流则通过时间戳或定时器控制“匀速发车”，确保固定间隔执行。
防抖（debounce）函数为什么能避免高频触发？
防抖的核心是「等一等」：只要事件持续触发，就不断重置定时器，只在最后一次触发后延迟执行。典型场景是搜索框输入、窗口 resize 监听——用户还没停手，就不急着查 API 或重绘。
容易踩的坑：clearTimeout 必须作用于上一次保存的定时器 ID，否则会漏清；且首次调用时 timerId 应为 null 或 undefined，避免未声明报错。
实操建议：
- 用闭包保存
timerId，避免全局污染 - 支持立即执行模式（
immediate = true）：首次触发立刻运行，后续进入等待状态 - 注意
this和参数传递，推荐用func.apply(this, args)而非直接调用
function debounce(func, delay, immediate = false) {
let timerId = null;
return function(...args) {
const callNow = immediate && !timerId;
clearTimeout(timerId);
timerId = setTimeout(() => {
timerId = null;
if (!immediate) func.apply(this, args);
}, delay);
if (callNow) func.apply(this, args);
};
}节流（throttle）函数怎么保证固定频率执行？
节流是「匀速发车」：无论事件多快，函数最多每隔指定时间执行一次。适用于鼠标拖拽、滚动监听（scroll）、Canvas 动画帧控制等需要稳定节奏的场景。
立即学习“Java免费学习笔记（深入）”；
关键区别在于判断逻辑：不能只靠定时器，否则可能因触发间隙短导致漏执行；常见实现分「定时器版」和「时间戳版」，后者更精准但无法保证首次立即执行。
实操建议：
- 时间戳版节流：记录上次执行时间，每次触发比较
Date.now() - lastTime >= delay - 定时器版节流：用
setTimeout控制「锁定期」，期间忽略新触发，到期后解锁 - 两者可组合（如 Lodash 的
throttle）支持leading/trailing配置，按需启用首尾执行
function throttle(func, delay) {
let lastTime = 0;
return function(...args) {
const now = Date.now();
if (now - lastTime >= delay) {
func.apply(this, args);
lastTime = now;
}
};
}debounce 和 throttle 在事件绑定中怎么选？
选错会导致功能异常或性能没改善。核心判断依据是「你关心的是最后状态，还是中间过程」。
常见错误现象：
- 用
debounce处理滚动加载更多 → 滚动停住才请求，用户已划过目标区域，数据没加载出来 - 用
throttle处理搜索联想 → 输入停了还继续发请求，浪费带宽且结果滞后
使用场景对照：
-
debounce：输入校验、自动保存草稿、防重复提交（按钮点击） -
throttle：滚动位置上报、鼠标移动轨迹采样、Canvas 渲染帧率限制
性能影响：两者都减少函数调用次数，但 throttle 可能比 debounce 多执行几次；若 delay 设得过大（如 500ms），throttle 会明显卡顿，而 debounce 只是响应延迟。
实际项目里为什么常要手动清理 debounce/throttle 实例？
组件卸载、事件解绑、对象销毁时，不清理残留的定时器或闭包引用，会造成内存泄漏——尤其在 React/Vue 单页应用中，debounce 函数若被组件方法闭包持有，又没清除 setTimeout，定时器会一直跑，this 指向的旧组件实例也无法 GC。
实操建议：
- 把
debounce或throttle返回的函数存在变量里，方便后续clearTimeout或设为null - React 中可在
useEffect的清理函数里调用cancel（若封装了取消方法）或手动清定时器 - 不要在每次 render 都新建防抖函数，应提至组件外或用
useCallback缓存
复杂点在于：节流的时间戳版没有定时器可清，但闭包中的 lastTime 仍会滞留；真正安全的做法是让防抖/节流函数支持 .cancel() 方法，并在销毁时显式调用。
