防抖适合用户停止操作后执行的场景，如搜索联想、resize布局、表单校验；节流适合固定频率执行的场景，如滚动加载、鼠标移动追踪、Canvas动画。
防抖和节流不是为了“炫技”，而是解决真实场景下事件高频触发导致的性能问题或逻辑错误。比如用户狂点按钮、疯狂拖拽窗口、滚动加载列表——这些操作会瞬间触发几十上百次回调，若每次回调都执行耗时操作（如发请求、重绘 DOM、计算布局），轻则卡顿，重则页面崩溃或接口被限流。
防抖（debounce）适合什么场景？
防抖的核心是“等用户停下来再执行”。典型场景包括：搜索框输入联想、窗口 resize 后重新计算布局、表单输入校验。
- 用户每按一次键就清掉上一次定时器，只保留最后一次输入后的延迟执行
- 如果用户持续输入，
debounce函数永远不会真正执行回调，直到停顿超过设定时间 - 注意：不能用于需要即时响应的操作，比如鼠标移动轨迹记录
- 常见错误是把
immediate参数设为true却没处理好首次立即执行 + 后续清空逻辑，导致重复触发
function debounce(func, wait, immediate = false) {
let timeout;
return function(...args) {
const later = () => {
timeout = null;
if (!immediate) func(...args);
};
const callNow = immediate && !timeout;
clearTimeout(timeout);
timeout = setTimeout(later, wait);
if (callNow) func(...args);
};
}节流（throttle）适合什么场景？
节流强调“固定频率执行”，不管用户怎么猛刷事件，回调最多每隔一定时间执行一次。典型场景包括：滚动监听（懒加载）、鼠标移动追踪、Canvas 动画帧控制。
- 常用实现分“定时器版”和“时间戳版”：前者保证函数至少间隔
wait毫秒执行一次；后者保证函数在每个wait时间窗口内最多执行一次 - 定时器版可能造成最后一次事件被丢弃（例如用户快速滚动到底部后停止，但最后一段距离没触发加载）
- 时间戳版更贴近“匀速”，但需额外记录上次执行时间，逻辑稍复杂
- 不要在节流函数里直接修改依赖外部状态的变量，容易因闭包捕获旧值而出错
function throttle(func, wait) {
let previous = 0;
return function(...args) {
const now = Date.now();
if (now - previous >= wait) {
func(...args);
previous = now;
}
};
}
为什么不能只用 setTimeout 或 setInterval 替代？
因为它们不感知事件触发节奏，也不自动清理上下文。比如连续绑定 10 次 setTimeout 而没 clearTimeout，就会堆积 10 个定时器；而 debounce 内部已封装了清除逻辑。
立即学习“Java免费学习笔记（深入）”；
-
setTimeout是底层能力，debounce/throttle是针对事件流设计的控制策略 - 原生 API 不处理 this 绑定、参数透传、执行时机边界（如立即执行 vs 延迟执行）等问题
- 现代框架（React/Vue）中若在组件卸载后仍执行节流回调，可能引发 “Can't perform a React state update on an unmounted component” 错误，需配合清理函数
- Lodash 的
debounce支持cancel、flush方法，手写简易版往往忽略这些可中断性需求
真正难的不是写出一个能跑的 debounce，而是在复杂交互中判断该用防抖还是节流、设置多少毫秒合理、是否要兼容服务端渲染或 SSR 环境下的定时器失效问题——这些细节，往往在压测或用户反馈卡顿后才暴露出来。
