JS防抖与节流闭包实现差异详解

防抖与节流作为前端性能优化的核心技巧，经常被开发者放在一起对比。两者虽然都借助闭包来保持内部状态，但闭包中锁定的变量类型、更新时机以及执行逻辑却存在本质差异。通俗地讲——防抖相当于“等静止后再触发”，节流则是“固定频率执行，避免过于密集”。它们不仅不能混为一谈，也无法共用同一套闭包结构。

首先来看防抖。它返回的内部函数需要持续访问外层作用域中定义的 timer 变量。这个 timer 并非每次调用都重新创建，而是被闭包“捕获”后长期保留。只要 timer 变量存在，clearTimeout 就能准确找到目标，清除上一次未完成的任务，并重新设置新的定时器。这样就实现了“等待操作停止后再执行”的效果。其核心逻辑在于：每次事件触发时，先清除之前的定时器，然后重新开始倒计时。 防抖闭包中保存的其实就是单个定时器 ID，通常使用 let timer = null 进行初始化。 每次触发时，先执行 clearTimeout(timer)，再调用 setTimeout(...)。 它并不关心“上次什么时间执行”，只关注“上一个定时器是否仍然存在”。 如果不使用闭包，timer 每次都会变成局部变量，clearTimeout 将无法找到需要清除的目标，防抖机制便会失效。 接下来看节流。节流需要跨越多次调用感知时间或状态信息，因此闭包中保存的通常是 lastTime（时间戳方式）或 canRun（开关标志方式）。时间戳法通过计算时间差来决定是否允许执行，开关法通过布尔值控制执行入口。无论采用哪种方式，都依赖闭包来确保变量不会随着函数调用结束而被销毁。 时间戳版本的闭包保存 let lastTime = 0，每次调用判断 Date.now() - lastTime >= interval 是否成立。 开关版本闭包保存 let canRun = true，执行前检查标志，执行后设为 false，定时器完成后再重置为 true。 这两种实现都要求变量能够在多次事件回调之间共享，否则每次调用都相当于从零开始，节流就会退化为普通的函数执行。 闭包在此不是可选项，而是机制成立的必要前提——缺少闭包，函数就失去了记忆能力。 既然都基于闭包，能否设计一套通用的结构呢？答案是否定的。因为防抖和节流各自解决的是完全不同的问题：防抖是“等待操作静止”，节流是“控制执行节奏”。防抖无需知道上次执行的时间点，只需取消尚未完成的任务；节流则必须明确上次执行的时间或当前是否允许执行，否则无法判断“间隔是否足够”或“阀门是否开启”。变量的用途、初始化方式以及更新位置都存在差异——例如 lastTime 在函数实际执行后立即更新，而 timer 则在设置新的定时器时才被赋值。 timer 属于“待取消对象”，其生命周期由 clearTimeout 和 setTimeout 共同管理。 lastTime 是“时间参考点”，仅在函数实际执行后才进行刷新。 canRun 是“执行许可”，在进入函数时设为 false，退出时通过 setTimeout 再恢复为 true。 如果混用这些变量，会导致逻辑错误：例如用 timer 作为时间判断依据，或使用 lastTime 来执行 clearTimeout，都是不成立的。 在实际代码中，闭包的作用非常直观。通过函数签名就能识别闭包的角色：debounce(fn, delay) 返回一个函数，该返回函数内部访问了外层的 timer；throttle(fn, interval) 同样返回一个函数，它访问的是外层的 lastTime 或 canRun。这些变量既不出现在参数中，也不挂载到全局，完全依靠作用域链从外层作用域“借用”——这正是闭包最朴素也最核心的用法。 所有标准实现都将状态变量声明在外层函数体内，而不是在内层事件回调中。 返回的函数即便被赋值给不同变量或绑定到不同 DOM 元素，每个函数实例依然拥有独立的闭包环境。 多个 debounce 调用之间互不干扰，正是因为每次调用都生成了自己的 timer 闭包。 闭包并非炫技，而是使“有状态的无状态函数”得以实现的基础机制。