防抖与节流需深入理解行为边界和执行时机，常见坑包括定时器未清除、this/arguments丢失、immediate误用、异步取消缺失、节流漏触发及不可控状态；选型应依需求本质与控制粒度而定。
防抖与节流不是“加个函数就完事”的黑盒工具，写错参数、混用模式、忽略 this 和 arguments、忽视清理逻辑，都可能让优化变成 bug 源头。真正防坑的关键，在于理解行为边界、明确执行时机、守住闭包状态。
防抖最常踩的 4 个坑
1. 忘记清除定时器，导致内存泄漏或误执行
多次绑定防抖函数但未统一管理 timer 变量，旧定时器未被 clearTimeout，可能在页面卸载后仍触发回调（尤其在单页应用中）。
- 每次调用防抖函数必须返回新闭包，timer 必须定义在闭包内，不可全局共享
- 组件销毁前（如 React useEffect cleanup、Vue beforeUnmount）应手动调用防抖函数的 cancel 方法（若实现支持）
2. immediate 模式下 this 和 arguments 丢失
立即执行时若直接 func() 调用，会丢失事件上下文，导致 this 指向 window、event 对象无法获取。
- 必须用 func.apply(context, args) 或 func.call(context, ...args)
- 推荐封装时统一接收 context 和 args，并在两种模式下保持一致处理
3. 输入框防抖误用“立即执行”模式
搜索场景需要等用户停手再查，若设 immediate=true，则用户一输入就发请求，完全违背防抖初衷。
- 搜索、校验、resize 等“响应稳定态”场景，只用延迟执行（immediate=false，默认）
- 仅按钮点击防重复（如提交表单）才考虑 immediate=true：首次点击立刻生效，后续点击在 wait 内被忽略
4. 未兼容异步操作取消逻辑
防抖重置定时器，但已发出的请求（如 fetch）不会自动 abort，可能造成旧请求结果覆盖新请求数据。
- 需配合 AbortController 手动中止上一个请求
- 可在防抖函数内部维护 signalRef，每次新触发时调用 prevSignal?.abort()
节流容易忽略的 3 个细节
1. 时间戳版 vs 定时器版的行为差异
时间戳版（记录 lastTime）首调立即执行、尾调可能漏掉；定时器版（用 setTimeout 控制开关）首调延迟、但保证固定间隔内必有一次。
- 滚动监听需“持续反馈”，推荐时间戳版（更灵敏）
- 按钮点击防刷、接口限频需“强约束”，推荐定时器版（更可控）
2. 缺少“兜底执行”导致最后一次触发失效
纯定时器节流在事件停止后，若未触发新一轮定时器，最后一次操作可能永远不执行。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 工程级节流建议采用“时间戳 + 定时器”双机制：既按间隔执行，又在最后触发后追加一次（类似 _.throttle 的 leading & trailing 配置）
- 例如：用户快速拖拽结束，仍需触发一次 final position 更新
3. 忽视节流函数的可取消性与重置能力
节流状态（如 lastTime 或 timer）固化在闭包中，无法外部干预，调试或动态调整 wait 值时束手无策。
- 暴露 cancel() 方法清空 timer / lastTime
- 提供 setWait(newWait) 方法重置间隔，避免重建函数实例
选型与调试的实用口诀
看需求本质：要“最后一次才动” → 选防抖；要“每隔一阵就动一次” → 选节流。
- 输入搜索、窗口缩放、表单校验 → 防抖（延迟执行）
- 滚动监听、鼠标移动、按钮防刷、日志上报 → 节流（时间戳版优先）
- 既要首调响应，又要末次兜底 → 节流开启 leading + trailing
看控制粒度：能接受“完全丢弃中间态” → 防抖；必须保障“最低执行频率” → 节流。
- 防抖可能全程不执行（用户一直输/一直拖），节流至少每 wait ms 执行一次
- 对关键操作（如保存草稿、上报错误），慎用纯防抖
调试技巧：在防抖/节流函数内部 console.timeLog('debounced', Date.now())，对比原始事件触发频率，确认是否符合预期节奏；用 performance.now() 替代 Date.now() 提升精度。
工程化建议：别从零手写，但要懂它怎么坏
生产环境优先使用 Lodash 的 _.debounce 和 _.throttle，它们已处理 cancel、flush、maxWait、trailing 等边界；但必须清楚：
— leading: true 在节流中开启首调，trailing: true 开启末调；
— 防抖的 maxWait 是保底执行机制（防止用户一直操作导致永不执行）；
— 所有 Lodash 版本均返回带 cancel() 和 flush() 方法的对象，务必在组件卸载时调用 cancel()。
不复杂但容易忽略
