JS防抖与节流函数实现：闭包在状态保持中的应用

图 0：防抖与节流核心架构与闭包状态容器概览

一、闭包在跨调用私有状态保持中的机制

当浏览器监听 DOM 事件时，每次触发都会从任务队列中调度事件处理函数。在常规的函数执行流程中，每次函数调用都会在调用栈上创建独立的执行上下文（Execution Context），函数执行完毕后局部变量随即出栈被垃圾回收（GC）。这种“用完即销毁”的生命周期，无法记录诸如“上一次何时触发”或“当前是否存在未执行的定时器”等历史状态。

如果使用全局变量或挂载在全局对象上来暂存状态，固然能够跨调用读取，但会引入严重的副作用：不同业务组件之间的状态会互相污染，一旦同一页面中存在多个需要独立防抖的输入框，共享的全局定时器变量就会引发混乱。

闭包（Closure）优雅地解决了这一矛盾。通过在一个高阶工厂函数（如 debounce 或 throttle）中声明内部变量（例如 timer 或 previous），并返回一个事件响应函数，返回的函数会在其内部属性 [[Scopes]] 中永久保留对其定义时外层词法环境的引用。只要这个返回的包装函数仍然被 DOM 事件监听器或变量持有，JavaScript 引擎的垃圾回收器便不会释放这块私有内存。

图 1：闭包在状态保持中的作用域链与内存模型

如图 1 所示，外部工厂函数 debounce 仅在初始化阶段执行一次，随后弹出调用栈。保存在其词法环境中的 timer 与 fn 并未随之消亡，而是长驻于堆内存中。此后每一次高频事件触发，执行的都是返回的包装函数，该函数作为闭包消费者，可以直接操作同一份 timer，从而实现对后续调用的拦截、取消或更新。

二、防抖函数（Debounce）实现：重置周期的状态跃迁

防抖的策略可概括为“静止后才执行”。在连续的高频触发过程中，每次新的调用都会强制重置等待周期，只有当距离最后一次操作经过了指定的延迟时间（delay）且再无新输入时，目标业务函数才会被实际调用一次。

在防抖的闭包中，核心保持的状态是 timer（由 setTimeout 返回的标识符）。

1. 基础版防抖函数实现

/**
 * 基础防抖函数
 * @param {Function} fn 需要防抖的目标业务函数
 * @param {number} delay 等待延迟时间（毫秒）
 * @returns {Function} 具有闭包状态的事件包装函数
 */
function debounce(fn, delay = 300) {
  // 在外层作用域中声明持久状态变量
  let timer = null;

  return function (...args) {
    // 保留调用时的 this 上下文
    const context = this;

    // 若闭包中已存在未执行的定时器，立即清除
    if (timer !== null) {
      clearTimeout(timer);
    }

    // 重新开启定时器并更新闭包中的状态
    timer = setTimeout(() => {
      fn.apply(context, args);
      timer = null; // 执行后重置闭包状态
    }, delay);
  };
}

图 2：防抖执行时序与闭包状态跃迁推导

图 2 详细推导了四次状态演进过程：在 t = 150ms 时首次触发，闭包中的 timer 被赋值；在 t = 320ms 再次输入时，由于时间间隔仅 170ms 小于预设的 300ms，包装函数捕获到闭包中尚未释放的 ID_A 并执行 clearTimeout，同时把 timer 覆写为 ID_B；直到 t = 500ms 的最后一次触发后，系统在 300ms 内未收到任何新事件，最终在 t = 800ms 到达时准时触发目标函数，并把闭包状态重置为 null。

2. 支持立即执行的进阶防抖

在某些业务场景中（例如按钮防重复点击），我们希望在第一次点击时立刻触发操作，随后的快速连击均被拦截，直到停止点击并经过延迟期后，才恢复下一次立即触发的能力。这需要闭包额外判断当前是否处于“冷却状态”。

/**
 * 支持立即执行与手动取消的完整防抖函数
 */
function debounce(fn, delay = 300, immediate = false) {
  let timer = null;

  const debounced = function (...args) {
    const context = this;

    if (timer !== null) {
      clearTimeout(timer);
    }

    if (immediate) {
      // 若当前没有正在等待的定时器，说明处于初次触发或冷却已完成
      const callNow = !timer;

      // 无论是否立即执行，都需要启动定时器来维系冷却期
      timer = setTimeout(() => {
        timer = null; // 冷却结束，允许下次立即执行
      }, delay);

      if (callNow) {
        fn.apply(context, args);
      }
    } else {
      timer = setTimeout(() => {
        fn.apply(context, args);
        timer = null;
      }, delay);
    }
  };

  // 提供取消接口：在单页应用组件卸载时避免内存泄漏
  debounced.cancel = function () {
    if (timer !== null) {
      clearTimeout(timer);
      timer = null;
    }
  };

  return debounced;
}

三、节流函数（Throttle）实现：固定频率的状态推进

节流的策略是“匀速稀释”。当用户持续高频触发事件时，节流函数保证每隔固定时间周期（wait）只执行一次。无论事件流有多密集，输出结果都严格受控在设定的节拍之内。

根据闭包内部所维护状态的不同，节流通常有两种基础实现途径：

图 3：节流状态演进与双模式比对推导

1. 时间戳模式（闭包保持 previous 时间基准）

时间戳模式在闭包中保存一个时间基准变量 previous（初始化为 0）。每次事件触发时，获取当前时间戳 now，计算两者之差 now - previous。如果差值大于等于设定间隔 wait，则立即执行业务函数，并将闭包中的 previous 更新为当前时间。

function throttleTimestamp(fn, wait = 300) {
  let previous = 0; // 闭包持久保存上一次执行的物理时间戳

  return function (...args) {
    const now = Date.now();
    const context = this;

    if (now - previous >= wait) {
      fn.apply(context, args);
      previous = now; // 更新闭包状态
    }
  };
}

特点：因为 previous 初始为 0，第一次触发时 now - 0 > wait 必然成立，所以具备即时响应性（leading 触发）；但当用户停止操作后，最后一次未满 wait 周期的调用会被彻底丢弃，缺乏尾部执行（no trailing）。

2. 定时器模式（闭包保持占用标志 timer）

定时器模式在闭包中维护 timer 句柄充当“锁”。当触发事件时，检查 timer 是否为空；若为空，则创建一个 setTimeout，在回调执行完毕后将 timer 置空解锁；若 timer 已存在，则直接忽略本次触发。

function throttleTimer(fn, wait = 300) {
  let timer = null; // 闭包作为占用锁

  return function (...args) {
    const context = this;

    if (!timer) {
      timer = setTimeout(() => {
        timer = null; // 释放锁，允许下个周期进入
        fn.apply(context, args);
      }, wait);
    }
  };
}

特点：首次触发必须等待 wait 毫秒后才能执行，初期存在明显的迟滞感；但在连续事件停止后，已经进入定时器的最后一次操作仍会执行完毕，具备尾部补偿（trailing 触发）。

3. 工业级融合版：兼顾头部响应与尾部执行

在主流工具库（如 Lodash）中，节流通常将两者融合，闭包同时管理 previous 与 timer，精确计算剩余等待时间 remaining = wait - (now - previous)，实现兼备首次即时响应与停顿后尾部调用的完整节流。

/**
 * 工业级双模式节流函数
 * @param {Function} fn 目标函数
 * @param {number} wait 时间窗口间隔
 * @param {Object} options 配置 leading 与 trailing
 */
function throttle(fn, wait = 300, options = {}) {
  let timer = null;
  let previous = 0;
  const leading = options.leading !== false;
  const trailing = options.trailing !== false;

  const throttled = function (...args) {
    const now = Date.now();
    const context = this;

    // 若禁用首次立即执行，且 previous 为 0，则将 previous 同步为当前时间
    if (!previous && !leading) {
      previous = now;
    }

    const remaining = wait - (now - previous);

    // 已经跨越周期或系统时间异常时立即触发
    if (remaining <= 0 || remaining > wait) {
      if (timer) {
        clearTimeout(timer);
        timer = null;
      }
      previous = now;
      fn.apply(context, args);
    } else if (!timer && trailing) {
      // 在剩余时间内安排尾部延迟执行
      timer = setTimeout(() => {
        previous = leading ? Date.now() : 0;
        timer = null;
        fn.apply(context, args);
      }, remaining);
    }
  };

  throttled.cancel = function () {
    clearTimeout(timer);
    timer = null;
    previous = 0;
  };

  return throttled;
}

四、防抖与节流对比及技术选型

开发者在选型时常常混淆两者的适用边界。判断的核心依据在于：业务逻辑是关注事件触发的“最终静态结果”，还是需要操作过程中的“持续动态反馈”？

图 4：防抖与节流机制对比及技术选型决策树

五、工程实践中的关键注意事项

在实际框架与项目开发中，使用基于闭包的防抖与节流时，需要特别防范以下常见缺陷：

• 组件卸载时的异步闭包泄漏： 在 React / Vue 等单页应用中，如果给窗口或元素绑定了防抖函数，当组件被销毁而闭包内的定时器仍未到期时，定时器将在组件卸载后继续触发，可能导致对已卸载组件执行 setState 或更新不存在的 DOM。因此必须显式暴露并调用 cancel 方法清理闭包。
• 正确的 this 与参数绑定： 内部返回的包装函数不能使用箭头函数直接作为最外层，必须保留普通函数声明以便正确捕获 DOM 监听器注入的 this（指向触发事件的 DOM 元素）及 event 事件对象，再利用 fn.apply(context, args) 原样透传。
• React Hooks 中的闭包陷阱： 在函数式组件中，组件每次 re-render 都会重新执行整段函数代码。若直接在组件内写 const handleClick = debounce(fn, 300)，每次渲染都会产生一个全新的闭包实例，导致每次点击都在不同的 timer 上操作，防抖彻底失效。应配合 useCallback 或 useRef 固化闭包实例引用。