type
status
date
slug
summary
tags
category
icon
password
一、功能需求与基本概念
防抖（debounce）
在连续触发事件后，只在触发结束后一段延迟才执行回调。
- 可选项：
leading: 首次触发时立即执行一次。trailing: 最后一次触发后延迟执行一次。
二、初始的两种极端实现
2.1 仅 leading 模式（首次立即执行）
- 只有首次触发立即执行。
- 冷却期内后续触发均被忽略。
2.2 仅 trailing 模式（最后一次延迟执行）
- 事件触发停止后一段延迟执行回调。
- 每次触发都重置延迟时间。
三、合并两种模式：debounceV1
要同时支持
leading 与 trailing 选项，需要按情况进行判断，初步的实现分成了三个分支：四、观察冗余，合并 Block 1 与 Block 3
通过观察发现：
- Block 1 与 Block 3 都是「延迟执行 trailing」。
- 区别是 Block 1 会先清除已有定时器，而 Block 3 没有。
考虑到执行
clearTimeout(null) 是安全的，可以在 Block 3 前增加 clearTimeout(timer)，将二者统一：五、合并后的状态组合表（timer × leading）
序号 | timer 存在 | leading | 逻辑行为 |
1 | false | false | 延迟执行 trailing（合并后的统一逻辑） |
2 | false | true | 立即执行 leading |
3 | true | false | 延迟执行 trailing（合并后的统一逻辑） |
4 | true | true | 延迟执行 trailing（合并后的统一逻辑） |
通过上述调整，情况 1、3、4 均统一处理，仅情况 2 为特殊情况。
六、最终实现：debounceV2
基于以上优化，最终简化成两个清晰的分支：
七、实现过程小结
从初始的两个极端实现（
leading、trailing），再到合并的初始版本（V1），最终通过冗余分析与分支合并，得到更精炼的最终版本（V2）。以上即是完整的 debounce 函数一步步优化的详细思路。