防抖的核心是“等停”而非延迟，依赖闭包维持timer私有状态以实现定时器清除与重设，并需通过闭包保存this及参数确保上下文正确，支持immediate模式时亦靠闭包状态判断执行时机。
防抖的核心不是“延迟”，而是“等停”。它不承诺固定延后执行，而是每次新触发都重置等待窗口——只有当事件彻底静默满设定时长，才真正调用目标函数。闭包在这里不是锦上添花的技巧，而是实现这一逻辑的必要基础设施。
闭包为什么不可替代
防抖必须持续追踪一个定时器 ID（timer），用于在下一次触发时清除前序任务。这个变量不能：
- 放在全局：多个防抖实例会互相覆盖，比如搜索框和窗口 resize 共用一个 timer 就会出错
- 写在返回函数内部：每次调用都会新建 timer，旧定时器无法被清除，导致多次执行
- 靠参数传入：调用方无法也不该管理底层定时器状态
闭包提供唯一解法：外层函数定义 timer，返回的包装函数通过作用域链“记住”它——私有、持久、与当前防抖实例强绑定。
timer 的生命周期与关键操作
timer 变量本身只是个数字（setTimeout 返回的 ID），但它承载着整个防抖的状态机：
- 初始为 null 或 undefined，表示无待执行任务
- 每次触发先 clearTimeout(timer)，无论它是否有效（安全操作）
- 紧接着设置新 setTimeout，并把返回值赋给 timer，建立新待执行节点
- 定时器回调执行后，通常将 timer 置为 null（可选但推荐），便于下次判断是否为首次触发
这个流程依赖闭包维持 timer 引用不变，否则 clearTimeout 就像对空气挥拳——找不到要清的对象。
this 和参数的正确传递
事件监听中，this 指向触发元素（如 input），而 setTimeout 回调默认在全局上下文执行，直接 fn() 会让 this 变成 window。闭包内需显式保存并还原上下文：
- 在包装函数开头用 const context = this 记录调用时的 this
- 用 fn.apply(context, arguments) 或 fn.call(context, ...arguments) 执行
- 推荐用剩余参数语法 function(...args) { fn.apply(this, args) }，语义更清晰
这步看似外围，实则决定防抖函数能否在真实业务中可靠工作——比如调用 this.value、this.dispatchEvent 等操作。
支持 immediate 的扩展逻辑
有些场景需要“首次立即执行，后续仍按防抖走”，比如按钮点击反馈+防连点。这时闭包还需多记一个状态：
- 除 timer 外，不再需要额外变量；仅靠 timer 是否为 null 就能判断是否首次
- immediate 为 true 且 timer 为空 → 立即执行 fn
- 之后所有触发仍走 clearTimeout + setTimeout 流程，保证后续只响应最后一次
- 定时器回调里需区分：immediate 模式下只在 !immediate 时执行 fn，避免重复
所有这些分支判断，都建立在闭包提供的稳定私有状态空间之上。
