闭包的本质：从作用域链到内存泄漏的完整认知

很多 JavaScript 学习者对“闭包”的定义都背得很熟：函数内部返回一个函数，内部函数还能访问外部函数的变量。但真到项目里，循环绑定事件、定时器里的旧数据、组件卸载后还在执行的异步回调，问题一个接一个。闭包不是“函数套函数”这个语法现象，它是一整套作用域机制在运行时留下的痕迹。这篇文章我打算从作用域链和执行上下文讲起，再用真实项目里的场景收尾，希望能帮你把“闭包”从名词变成可观测、可调试的东西。

1. 闭包不是“函数套函数”，是作用域链在保留现场

很多人把闭包理解为“外层函数套内层函数，内层函数访问外层变量”的写法，这个理解在今天看来太表面了。要真正踩稳闭包，得先搞清楚 JavaScript 凭什么能在一个函数执行完之后，还能让另一个函数继续访问它的变量。答案的起点是词法作用域。

1.1 词法作用域：函数出生时就定好了“找变量”的路线

JavaScript 使用的是词法作用域，也叫静态作用域。一个函数能访问哪些变量，在它被定义的那一刻就已经确定了，而不是在它被调用的时候才决定。这个“定义时的位置”，就是整个变量查找链路的起点。

我刚开始学的时候也犯过迷糊，总觉得函数在哪个地方被调用，就应该看到哪个地方的变量。但实际不是这样。看这个例子：

javascript复制const name = 'outside';

function outer() {
  const name = 'inside';

  function inner() {
    console.log(name);
  }

  inner();
}

outer(); // 输出 'inside'

inner 定义在 outer 内部，所以它的作用域链是：自己的环境 -> outer 的环境 -> 全局环境。无论之后你把 inner 拿到哪里去调用，它看到的还是这条固定的查找路线。换句话说，函数出生在哪个作用域，它一辈子都记得那个作用域。

这个“出生地”概念非常关键，因为闭包不是从“返回函数”这种写法里生出来的，而是从“函数定义时的环境引用”里生出来的。如果你写了一个函数返回另一个函数，但内层函数没有引用外层变量，那其实不算真正意义上的闭包场景，最多算一个高阶函数。

1.2 闭包形成的过程，以及“闭的是哪一层”

我们看一段最典型的闭包代码：

javascript复制function createCounter() {
  let count = 0;

  return function () {
    count += 1;
    return count;
  };
}

const counterA = createCounter();
const counterB = createCounter();

console.log(counterA()); // 1
console.log(counterA()); // 2
console.log(counterB()); // 1

createCounter 每次被调用，都会生成一块独立的局部环境，count 分别属于不同环境。counterA 和 counterB 各自闭着各自的 count。这就是“闭的是环境，不是变量值”的含义。

这里有两个很容易忽略的点。

第一，闭包捕获的不是 count 在某一时刻的值，而是 count 这个名字与当前存储位置之间的绑定关系。之后你给 count 赋什么新值，闭包看到的就是新值。

第二，createCounter 执行完之后，它的执行上下文已经从调用栈弹出了，但堆内存里的那份词法环境还在，因为 inner 函数对象的内部引用还指着它。这个“栈上销毁，堆上保留”的状态，是很多新手理解闭包的坎。

我习惯用一个比喻来解释：你把一份合同的原件放在保险柜里，然后把保险柜钥匙交给了另一个人。即使你人离开了办公室，保险柜本身并不会消失，因为钥匙还在别人手里。闭包也是这样，外部函数执行完相当于人走了，但内部函数还握着那段环境的钥匙。

2. 深入执行上下文：闭包能“记住”外层变量，凭的是什么

知道了闭包是“环境的引用”，还需要弄清楚这个环境在 JavaScript 引擎里到底长什么样，以及为什么函数执行完环境还能存活。

2.1 函数执行上下文的创建与销毁：栈上的“弹栈”不等于一切都消失

每次调用函数，JavaScript 引擎都会创建一个函数执行上下文，并把它压入调用栈。函数正常结束后，这个上下文从栈上弹出。这一段过程大多数人都知道。

但很多人不知道的是，执行上下文里维护的“词法环境”，本身是一个保存在堆内存中的对象。调用栈弹出只是把“当前正在执行的记录”拿掉了，不代表这个堆里的词法环境一定被销毁。它是否还活着，取决于还有没有其他对象引用它。

你可以这样理解：调用栈是前台接待，函数执行时前台提着一个文件袋在工作；函数执行完，前台把手里的活放下了。但如果文件袋被某个内部函数带走了，这份文件就没有被丢弃，而是留在了后台的档案柜里。闭包返回的那个函数，就是带走文件袋的人。

所以，“函数执行完变量就没了”这句话在无闭包场景下是对的，但只要有闭包存在，变量环境就会继续活着，直到没有任何引用指向它。

2.2 内部函数的 [[Environment]] 属性：闭包背后的引用机制

ECMAScript 规范里，每个函数对象都有一个内部插槽，叫做 [[Environment]]，保存的是函数创建时所在词法环境的引用。这个属性在普通代码里读不到，但引擎在函数调用时会拿它来建立作用域链。

我们回到 createCounter 的例子。createCounter 执行的瞬间，函数体内部定义了一个匿名函数。此时这个匿名函数的 [[Environment]] 被设置为 createCounter 当前的词法环境，也就是那个包含 count 变量的环境。当 createCounter 把这个匿名函数 return 出去，外部变量 counterA 就拿到了这个函数。函数对象带着 [[Environment]] 一起被赋值到了外部，于是 createCounter 的词法环境也被间接引用着，不会被垃圾回收。

等后面调用 counterA() 时，引擎会为这次调用创建新的执行上下文，然后让这个新上下文的 outer 指向上面的 [[Environment]]。这样，匿名函数内部访问 count 时，就会沿着这条链找到 count 所在的环境。

这也能解释一个经典陷阱：闭包不会保存“外部函数调用那一刻的变量快照”，它保存的是“变量所在环境的引用”。变量后来的变化，闭包全部看得到。

javascript复制function later() {
  let msg = 'hello';

  setTimeout(() => {
    console.log(msg);
  }, 1000);

  msg = 'world';
}

later(); // 1 秒后输出 world，不是 hello

定时器回调形成的闭包捕获的是 msg 这个绑定，不是 1 秒前的值。等到回调真正执行，msg 已经被改成 world。这个细节看懂了，很多异步闭包的问题就都有了解释。

3. 一道必考的循环闭包题，理解它胜过背十道面试题

闭包相关的面试题，十个里有八个是关于循环的。很多人靠背结果应付过去了，但换个场景照样懵。我建议把这个经典问题彻底拆开。

3.1 为什么 for 循环里的 var 闭包结果全是 5

看这段代码：

javascript复制for (var i = 0; i < 5; i++) {
  setTimeout(() => {
    console.log(i);
  }, 100);
}

输出不是 0 1 2 3 4，而是 5 5 5 5 5。

原因其实不复杂：var 声明的 i 作用域在函数或全局环境中，for 循环每一轮迭代都不会为 i 创建新的词法绑定。五个定时器回调虽然是在不同的迭代里定义的，但它们共享同一个 i 绑定。等到 100 毫秒后事件循环开始执行回调，循环早就结束了，i 停留在 5，于是五个回调全部打印 5。

这里面的关键不是“延迟执行”，而是“共享绑定”。如果你把 setTimeout 改成同步调用，输出的反而是 0 到 4，因为每个回调都在当轮迭代立即执行了。可见问题本质不在闭包本身，而在于闭包引用的是同一个变量环境。

3.2 let、立即执行函数与块级作用域分别做了什么

如果是用 let 声明循环变量：

javascript复制for (let i = 0; i < 5; i++) {
  setTimeout(() => {
    console.log(i);
  }, 100);
}

结果就是 0 1 2 3 4。因为 let 在每一轮迭代都会创建一个新的词法环境，并把 i 绑定到新环境里。每轮注册的回调闭着各自的 i，互不干扰。

在 ES6 之前，解决这个问题的标准写法是立即执行函数：

javascript复制for (var i = 0; i < 5; i++) {
  (function (j) {
    setTimeout(() => {
      console.log(j);
    }, 100);
  })(i);
}

这里 IIFE 的形参 j 在函数每次调用时都会创建新的环境，相当于手动给每一轮迭代造了一个独立作用域。ES6 之后，我更推荐直接用 let，代码可读性好很多。但要清楚，let 不是消灭了闭包，而是让闭包捕获的是一轮轮新环境。

这个表格是所有循环闭包问题的“总纲”。事件监听里也同理。你给 5 个按钮绑定点击事件，如果用 var 写循环，点哪个按钮拿到的都是最后一个索引。问题完全是同一个。

4. 闭包的高频实战场景：模块化封装、柯里化与防抖节流

面试通过只是顺手，闭包在真实项目里的存在感远比想象中高。很多你每天都在用的写法，底层都是闭包。

4.1 用闭包实现私有变量：模块化代码的原始形态

在 class 的私有字段和 ES Module 普及之前，闭包是模拟私有变量的主力方案。其实就算现在，闭包封装依然在很多工具函数里非常实用。

javascript复制const User = (function () {
  let token = null;

  return {
    login(value) {
      token = value;
    },
    getToken() {
      return token;
    },
  };
})();

外部代码只能通过 login 和 getToken 操作 token，直接访问不到 token 变量。这就是模块模式。它的价值在于把状态收拢在一个封闭环境里，避免污染全局，也避免外部不经检查就随意改动内部状态。

我在实际项目里经常用这种模式做全局状态管理的小型替代。业务简单时，不需要引入 Vuex 或 Redux 这种重量级方案，一个闭包配合几个方法就能维持一套内部状态。

4.2 柯里化：闭包让函数变成可配置的“半成品”

柯里化是函数式编程里非常实用的技术，核心就是利用闭包把参数分阶段收集。看这个例子：

javascript复制const multiply = (a) => (b) => a * b;

const double = multiply(2);
console.log(double(10)); // 20

const triple = multiply(3);
console.log(triple(10)); // 30

multiply 接收 2 之后，返回的箭头函数闭住了 a 的值，于是 double 就成了一个固定“翻倍”的函数。这个过程本质上是参数复用：先固化一部分参数，返回一个等待剩余参数的函数。

柯里化在业务里的应用场景很多。比如封装一个带有固定前缀的日志函数：

javascript复制const createLogger = (prefix) => (message) => console.log(`[${prefix}] ${message}`);
const requestLogger = createLogger('request');
const responseLogger = createLogger('response');

requestLogger('sending...');
responseLogger('received...');

这样做的好处是职责单一，基础逻辑写一次，后续通过闭包配置不同的行为。

4.3 防抖与节流：闭包维护定时器状态的标准范式

防抖和节流是闭包在前端性能优化中最出名的应用。看防抖的标准实现：

javascript复制function debounce(fn, delay = 300) {
  let timer = null;

  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => {
      fn.apply(this, args);
    }, delay);
  };
}

这里的 timer 就是被闭包保存的状态。每次返回的防抖函数被调用，都能拿到上一次的定时器，然后清掉重开。如果不用闭包，timer 就只能挂到全局或者函数对象属性上，很容易被别的逻辑干扰。

节流的原理也类似，用闭包保存上一次执行时间或者 timer 状态，控制调用频率：

javascript复制function throttle(fn, interval = 500) {
  let last = 0;

  return function (...args) {
    const now = Date.now();
    if (now - last >= interval) {
      last = now;
      fn.apply(this, args);
    }
  };
}

这里我要特别提醒一个细节：防抖/节流返回函数里的 this 绑定。如果用箭头函数包住 fn 调用，且不通过 apply/call 传 this，在事件监听场景下，fn 内部的 this 会变成外层词法作用域的 this，而不是当前元素。上面代码里我用 fn.apply(this, args) 就是为了把 this 原样传进去。这个坑我见过太多人踩了，闭包完整地保留了上下文，但前提是你得把 this 也当成一个普通参数一样对待。

5. 闭包与内存：引用该释放没释放，问题出在哪

聊闭包绕不开内存问题。但我想先纠正一个观点：闭包本身不必然造成内存泄漏。泄漏是因为闭包引用了不再需要的数据，而且这个引用一直没被断开。

5.1 闭包导致内存泄漏的典型链路

举一个生活中很常见的泄漏场景：全局数组里不停堆积闭包。

javascript复制const handlers = [];

function trackScroll() {
  const heavyData = new Array(1000000).fill('x');

  handlers.push(() => {
    console.log(heavyData.length);
  });
}

每次调用 trackScroll，heavyData 都会被闭包保存，同时又被 push 进全局数组 handlers。如果业务上不断调用 trackScroll，但 handlers 里的元素永远不被清理，那 heavyData 就会一直堆在内存里，页面越来越卡。

还有一种更隐蔽的泄漏，和事件监听有关：

javascript复制function attach() {
  const node = document.getElementById('large');
  const handler = () => {
    console.log(node.dataset);
  };

  window.addEventListener('scroll', handler);
}

attach();

attach 把 handler 挂到了 window 上，handler 又通过闭包持有 node。如果 node 在合适时机被移除，但 handler 仍然挂在 window 上，那么 node 对应的 DOM 对象就无法被回收，因为闭包里的引用还指着它。每次调用 attach 都会新增一个永久监听器，内存自然只增不减。

这些问题不是闭包“造”出来的，而是使用方式不正。闭包只是提供了一种引用机制，让变量被长期保存。保存得对不对，取决于开发者有没有在合适的时机清理引用。

5.2 实际排查泄漏的方法，以及“闭包不是原罪”

排查闭包相关的内存问题，我最常用的是 Chrome DevTools 的 Memory 面板。

先录制一个堆快照，在业务场景里反复触发一些操作，再录制第二个快照，然后手动触发几次垃圾回收，如果内存没有明显回落，说明可能有泄漏。然后在堆快照里搜索 detached、闭包函数的名称、或者可疑的数据结构，看它的 Retainers 引用链，通常能找到是哪个全局对象在持续持有它。

另外，Sources 面板打断点也可以直接观察闭包变量。在闭包内部代码处设置断点，执行到时展开右侧 Scope 面板，会看到 Closure 层级，里面列出当前函数捕获了哪些外部变量以及它们的当前值。这是调试闭包最直接的手段，比 console.log 打印一个对象指针要靠谱得多。

我还见过一种“所有闭包都有罪”的团队规范，动不动就要求消灭闭包。这是因噎废食。闭包是 JavaScript 的重要能力，完全不用闭包，你连事件监听里的状态保存都做不干净。正确的态度是：搞清楚它到底持有什么，按需释放。

6. 真实项目中常见的闭包运行时报错与调试思路

闭包在普通文本教程里看起来很干净，但进了真实项目，它会和各种生命周期问题纠缠在一起，产生一些让人摸不着头脑的报错。

6.1 “a JavaScript error occurred in the main process”这类报错和闭包的关系

看到“a JavaScript error occurred in the main process”这个报错，很多人的第一反应是去查框架或者运行环境的 bug。但我排查过几次后，发现其中一类根因跟闭包的生命周期有关。

在 Electron 这类双进程架构中，主进程和渲染进程的生命周期很长，而且互相通信是异步的。如果渲染进程里某个模块向主进程注册了一个事件回调，这个回调里闭合了模块内部的数据，但模块销毁后没有注销回调，那这个闭包就会一直活着。等到后续某个时间点，主进程再向渲染进程发送消息，回调被触发时，里面引用的对象可能已经处于销毁后的异常状态，于是各种奇怪的运行时报错就出现了。

这类问题的排查思路，不是直接去搜报错信息，而是去检查所有还挂在全局事件或跨模块事件上的回调函数。闭包不会主动销毁，它只会忠实地把外部环境保存下去。环境里的数据已经不符合预期，回调执行时就会炸。

在前端框架里也有类似情况。比如 React 组件卸载后，某个闭包定时器仍然调用 setState。React 18 里会直接抛“Can't perform a React state update on an unmounted component”这类警告，本质上也是闭包的生命周期超出了组件生命周期。

这类问题最好的处理方式就是“及时拆引用”：组件卸载时清理定时器，模块销毁时移除事件监听，全局数组不再使用时清空。闭包本身没有错，错的是它被留在了不该存在的生命周期里。

6.2 在浏览器控制台打断点观察闭包变量：调试闭包的正确姿势

调试闭包，我强烈建议养成看 Scope 面板的习惯。

在闭包内部代码处打断点，比如：

javascript复制function createGreeter(name) {
  const prefix = 'Hello';

  return function () {
    debugger; // 在这里设置断点
    console.log(`${prefix}, ${name}`);
  };
}

const greet = createGreeter('Tom');
greet();

运行到 debugger 时，右侧 Scope 面板里会显示 Closure 区域，你能清楚看到 prefix 和 name 被捕获在闭包里。这个信息量比 console.log 大得多，因为它直接展示了引擎眼中闭包到底保住了哪些变量。

如果你想验证某个对象是否真的被闭包引用导致无法回收，可以借助 WeakRef 和 FinalizationRegistry。WeakRef 不会阻止垃圾回收，所以如果闭包持有某个对象，把外部引用置空后，手动 GC 一次，再检查 WeakRef.deref() 是否返回 undefined。如果返回 undefined，说明对象已经被回收；如果还能拿到，说明闭包还持有它。

javascript复制let target = { name: 'leak' };
const ref = new WeakRef(target);
const closure = () => target.name;

target = null;

// 手动触发 GC 后
console.log(ref.deref()); // 可能变成 undefined，也可能仍有对象，取决于是否被闭包引用

这个实验做完，你就能直观感受到“闭包持有没有被断开”的含义。断点和 WeakRef 都用上之后，闭包就不再是抽象概念，而是一个可以观测、可以验证的运行时事实。

我自己在实际项目里养成了一个习惯：写闭包时先想清楚三个问题——这个闭包会被谁持有？它应该活多久？在哪个生命周期节点断开引用？这三个问题想透了，闭包就基本不会给你带来太多运行时麻烦。