立即执行版本首次触发即执行，后续在冷却期内忽略；延迟版本则等待最后一次触发后延时执行。前者适用于需即时反馈的场景（如按钮点击），后者适用于需收敛结果的场景（如搜索联想）。
函数防抖（Debounce）的“立即执行版本”和“延迟版本”，核心区别在于：第一次触发时是否立刻执行，还是等停止触发后才执行。两者都用于控制高频事件（如 resize、input、scroll）的执行频率，但适用场景不同。
延迟执行版本（标准防抖）
最常见、最典型的防抖实现：在最后一次触发后等待指定时间，若期间无新触发，则执行函数；一旦中间有新触发，就重置计时器。
- 适用于搜索框输入联想、窗口尺寸调整后的布局重排等——需要等用户“停下来”再响应
- 不会在首次输入/操作时立刻执行，存在明显延迟（比如 wait=300ms，用户输完要等300ms才发请求）
- 典型写法中用 setTimeout + clearTimeout 管理定时器，闭包保存 timer 引用
立即执行版本（leading edge debounce）
在第一次触发时**立刻执行**函数，之后进入“冷却期”；冷却期内的新触发不执行，冷却期结束后下一次触发又会立刻执行（即“首次立即 + 后续节流式抑制”）。
- 适合需要快速反馈的场景，比如按钮点击防重复提交（点一下马上提交，但连续猛点只认第一次）
- 关键在于记录上一次执行时间，每次触发时判断是否已过冷却期；也可用 flag + 定时器组合实现
- 注意：它不是“每次触发都立即执行”，而是“每个冷却周期内仅首次触发立即执行”
如何选择？看交互意图
延迟版本强调“收敛结果”，适合异步请求、渲染优化；立即版本强调“及时响应”，适合用户操作确认、状态切换。
立即学习“Java免费学习笔记（深入）”；
- 搜索建议 → 用延迟版（等用户打完再查）
- 点赞按钮 → 用立即版（点下去就要有反馈，且防止连点）
- 可组合：有些库支持同时开启 leading 和 trailing（即首次立即 + 结尾补一次），但需谨慎，容易误触发
一个可配置的通用实现示意
用一个参数 immediate 控制行为：
- immediate = false → 标准延迟执行（trailing only）
- immediate = true → 首次立即执行，后续冷却（leading only）
- 内部通过时间戳比较或定时器状态（如 !timer）来判断是否该执行
