防抖的核心是“取消重来”，闭包通过持久化timeout、配置及上下文确保多次调用互不干扰，支持leading执行、异步Promise控制和this/参数正确传递。
防抖的核心不是“延迟执行”，而是“取消重来”——闭包让每次触发都能安全覆盖上一次的定时器，同时保留上下文、参数和配置状态。真正影响效果的，是 wait 时间、是否立即执行、是否需要 this 绑定、以及如何处理异步回调。
闭包如何支撑防抖的稳定性
防抖函数返回一个新函数，这个函数内部访问外层函数定义的 timeout 变量。由于 JavaScript 的作用域链机制，即使外层函数执行完毕，这个变量仍被内层函数持续持有——这就是闭包。它确保：
- 每次调用都操作同一个 timer 引用，clearTimeout 才能真正清除前序任务
- wait 值、fn 引用、甚至自定义配置（如 leading、trailing）都被封闭在各自实例中，互不干扰
- 多个输入框、多个 resize 监听器可共用同一份 debounce 代码，却拥有完全独立的计时逻辑
支持立即执行的防抖（leading edge）
标准防抖只响应“停止后”，但有些场景需要“第一次就动”。比如用户点开搜索面板，希望立刻清空历史并聚焦输入框——这时需在首次触发时立即执行，后续再进入等待逻辑。
实现关键：用一个标志位 isInvoked 记录是否已执行过，配合时间戳判断是否在 wait 窗口内。闭包让这个状态始终与当前防抖实例绑定，不会被其他调用污染。
示例片段：
const debounced = debounce(() => console.log('run'), 300, { leading: true });兼容异步操作的防抖封装
当防抖包裹的是 async 函数（如 fetch 请求），直接 return Promise 会导致调用方无法 await 到结果。闭包可帮你缓存 resolve/reject，让外部拿到的是“最终那次”的 promise。
- 在 timeout 启动前，新建一个 Promise，并把 resolve 存入闭包变量
- clearTimeout 时 reject 当前 promise（可选），防止旧请求返回后误更新 UI
- setTimeout 触发时，才真正调用 fn 并 resolve 结果
这样，连续输入三次，只有最后一次的请求结果会被消费，UI 不会因旧响应而错乱。
避免 this 和参数丢失的细节处理
原生事件监听中，this 指向触发元素，arguments 是事件对象。若防抖函数不显式传递，内部 fn 就会丢失上下文。
正确做法是在闭包内保存 this 和 arguments，并在 setTimeout 中用 apply 或 call 还原：
fn.apply(context, args)更现代的写法是用展开运算符 + 箭头函数保持词法作用域，但闭包仍是底层保障——没有它，context 和 args 无法跨异步边界留存。
