JavaScript闭包是什么：从作用域链和执行上下文理解形成机制

作者：代码拾荒时间：2026-10-30 19:12:09浏览：643

深入解析JavaScript闭包的底层形成机制，从执行上下文栈的生命周期、词法作用域的确立到作用域链与堆内存引用，彻底讲透闭包为什么能保留外部变量及其实际应用边界。

简单来说，闭包（Closure）是指一个函数有权访问其外部词法作用域中的变量，即使外层函数已经执行结束且其执行上下文已从调用栈中弹出，这些变量依然得以在内存中驻留。初学者常将闭包视为一种特殊的语法黑魔法，但它其实是 JavaScript 语言在词法作用域判定、执行上下文栈调度以及垃圾回收机制三者协同工作时的必然产物。本文将通过具体代码配合底层执行图景，带你逐步拆解执行上下文生命周期、作用域链的锁定方式与堆内存保持机制，彻底搞清闭包的本质。

一、直观认识闭包：它解决了什么问题

在 JavaScript 中，函数内部声明的局部变量在正常情况下只在函数执行期间存在。当函数执行完成后，局部变量通常随执行流程的退出而被释放。然而，当我们从一个函数内部返回另一个函数并保留对其引用时，这种直觉规律被打破了。

我们先来看一段最基础的闭包计数器示例：

function createCounter() {
    let count = 0; // 外层函数的局部变量

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

// 得到内部函数引用
const counter = createCounter();

console.log(counter());
console.log(counter());
console.log(counter());

控制台输出结果

1
2
3

这段代码产生了一个关键疑问：当执行到 const counter = createCounter() 时，createCounter() 已经调用完毕并返回，按常规编程语言的栈帧管理逻辑，外层的局部变量 count 应当已经销毁。但为什么后续三次调用 counter() 时，不仅依然能读取到 count，而且其数值还能在之前的状态上持续递增？

这正是闭包的核心表象：函数不仅打包了自身的执行代码，还连同其诞生时所处的外部作用域变量引用一同“打包”持有着。要理解这背后的原因，必须深入到 JavaScript 引擎底层的两个核心构造：执行上下文（Execution Context）与作用域链（Scope Chain）。

二、底层机制一：执行上下文与调用栈的运作流程

JavaScript 代码在被引擎解析和执行时，并不是一次性直接在物理内存上平铺执行的，而是依赖于执行上下文（Execution Context，简称 EC）。执行上下文是评估和执行 JavaScript 代码的环境抽象，主要包含全局执行上下文和函数执行上下文。

当引擎进入一段可执行代码时，会建立相应的执行上下文，并将其压入调用栈（Call Stack）中。调用栈遵循后进先出（LIFO）的规则：

全局初始化：首先创建全局执行上下文（Global Execution Context），压入栈底。
函数调用：每当调用一个函数，引擎都会为该函数创建专属的函数执行上下文（Function Execution Context），并压入调用栈顶，开始执行函数体。
函数返回与出栈：当函数执行完毕并遇到 return 或执行至末尾时，该函数的执行上下文会从栈顶弹出，控制权交回下方的执行上下文。

在 ES6 标准及现代规范中，执行上下文内部包含着词法环境（Lexical Environment）组件。词法环境由两部分组成：

环境记录（Environment Record）：真正记录当前作用域内声明的变量、函数、参数等绑定的物理存储结构。
外部环境引用（Outer Lexical Environment Reference）：保存对上层（父级）词法环境的指针引用。

图 1：执行上下文栈 (Call Stack) 入栈、内部函数生成及外层函数执行完毕出栈的三个阶段推导

三、底层机制二：词法作用域与作用域链是如何确立的

理解了执行上下文的生命周期后，我们接着探讨变量的查找依据。许多初学者常犯的一个错误是：以为函数内部的变量查找取决于“它在哪里被调用”。这是动态作用域的概念，而 JavaScript 采用的是词法作用域（Lexical Scoping），即静态作用域。

1. 词法作用域的确立时机

词法作用域的核心准则是：函数的作用域在函数定义（编写代码）时就已经确定，而不是在函数调用时确定。在词法解析阶段，编译器根据函数在源码中的物理嵌套层级，静态地决定了该函数能够访问哪些上层变量。

2. 隐藏的内部属性：[[Scopes]]

在 JavaScript 规范与 V8 等主流引擎实现中，当一个函数对象被实例化创建时，引擎会在该函数对象上绑定一个不可直接通过代码访问的内部插槽（Internal Slot），记作 [[Scopes]]。

[[Scopes]] 本质上是一个有序列表（链表），保存着该函数创建时所在执行上下文所能访问到的所有父级词法环境对象。因此，不论这个函数未来被传递到何处（比如作为回调传递、赋值给全局变量、通过定时器异步触发），它的 [[Scopes]] 引用都已经牢牢固定。

3. 变量查找链的串联规则

当我们在调用 counter() 时，引擎为它创建全新的函数执行上下文：

首先在该函数的本地环境记录中查找 count 变量；
如果本地没有，顺着外部环境引用（Outer Reference，即此前由 [[Scopes]] 继承而来的父级词法环境）向上回溯；
在 createCounter 的词法环境中找到了 count，随即完成变量读取与修改；
如果在该层仍未找到，继续顺着外部引用向上直至全局词法环境；若全局仍然没有，在严格模式下抛出 ReferenceError。

图 2：作用域链结构、内部属性 [[Scopes]] 与堆中词法环境引用的架构关系

四、形成机制核心：为什么外部局部变量没有被垃圾回收

在主流编译型语言（如 C/C++）中，局部变量通常随调用栈指针的移动而直接被覆写废弃。但在 JavaScript 引擎中，栈（Stack）负责执行上下文的流动与调用时序调度，而堆（Heap）则负责复杂对象与需要跨调用周期存活的实体。

1. 垃圾回收机制的判定标准：标记清除法

现代 JavaScript 引擎（如 Chrome 的 V8、Firefox 的 SpiderMonkey）普遍采用标记清除算法（Mark-and-Sweep）配合分代收集来管理内存。垃圾回收器会定期从“根对象（GC Roots）”出发开始遍历：

全局对象（Window / globalThis）；
当前处于调用栈中的所有执行上下文中的局部变量和参数指针。

只要从 GC Roots 出发，通过引用指针能够最终寻址到的对象，即被视为可达的（Reachable），垃圾回收器绝不会将其销毁。反之，任何无法从 GC Roots 遍历到的孤立对象，都会被标记并随后回收。

2. 闭包场景下的引用链路分析

对照前面图 2 的架构，我们来梳理一条清晰的引用链路：

GC Root (全局对象 Window)
    ↳ 引用了全局变量 counter
        ↳ 引用了堆中的 匿名函数对象 (Function Object)
            ↳ 其内部插槽 [[Scopes]] 引用了 createCounter 的词法环境记录
                ↳ 记录内包含变量 count: 0

正是因为这条完整的强引用链路自始至终未曾断裂，即便 createCounter 的执行上下文在调用栈中早已灰飞烟灭，其对应的词法环境记录也无法被垃圾回收器判定为垃圾，只能继续完好地驻留在堆内存中，随时等待 counter() 的调用读取。

图 3：普通函数执行结束与闭包函数执行结束的垃圾回收判定及内存驻留状态对比

五、闭包的典型应用场景与工程价值

理解了闭包的底层机制后，我们来看它在实际前端与 Node.js 工程中如何发挥作用。闭包绝非仅仅是语言设计的副产品，而是 JavaScript 实现模块化与函数式编程的基石。

1. 模拟私有变量与数据封装（模块模式）

在 ES6 出现 class 私有字段（#privateField）之前，JavaScript 原生并没有私有属性关键字。闭包是实现数据私有化、防止外部直接篡改的唯一手段：

function createBankAccount(initialBalance) {
    let balance = initialBalance; // 外部无法通过实例直接访问此变量

    return {
        deposit(amount) {
            if (amount > 0) {
                balance += amount;
                return balance;
            }
            throw new Error("存款金额必须大于0");
        },
        withdraw(amount) {
            if (amount > 0 && amount <= balance) {
                balance -= amount;
                return balance;
            }
            throw new Error("余额不足或金额非法");
        },
        getBalance() {
            return balance;
        }
    };
}

const myAccount = createBankAccount(100);
myAccount.deposit(50);
console.log(myAccount.getBalance());
console.log(myAccount.balance); // 尝试直接读取私有变量

控制台输出结果

150
undefined

在这段代码中，balance 变量完全被封装在 createBankAccount 生成的闭包作用域内。外部只能通过暴露出的三个特定接口受控地读取与修改，实现了严密的封装性。

2. 函数柯里化与参数复用（Currying）

通过闭包，函数可以把前置参数先“记住”，返回一个定制化的新函数，减少重复参数传递：

// 通用日志格式化工厂
function makeLogger(moduleName) {
    return function(level, message) {
        const timestamp = "2026-10-30"; // 示例时间戳
        return `[${timestamp}] [${moduleName}] [${level.toUpperCase()}]: ${message}`;
    };
}

// 绑定不同的模块前缀
const authLogger = makeLogger("AUTH");
const paymentLogger = makeLogger("PAYMENT");

console.log(authLogger("info", "用户已登录 (UID: 1042)"));
console.log(paymentLogger("warn", "支付网关延迟较高: 480ms"));

控制台输出结果

[2026-10-30] [AUTH] [INFO]: 用户已登录 (UID: 1042)
[2026-10-30] [PAYMENT] [WARN]: 支付网关延迟较高: 480ms

3. 解决异步循环索引绑定的经典陷阱

在面试或老旧代码中常遇到如下循环打印问题。对比使用 var（函数作用域）和闭包（块级作用域 / IIFE）：

// 错误模式：共享同一个上下文中的 i
for (var i = 0; i < 3; i++) {
    setTimeout(function() {
        console.log("var 模式输出:", i);
    }, 10);
}

// 闭包解决：通过立即执行函数 IIFE 为每次迭代锁定独立的词法环境
for (var j = 0; j < 3; j++) {
    (function(lockedJ) {
        setTimeout(function() {
            console.log("IIFE 闭包输出:", lockedJ);
        }, 10);
    })(j);
}

控制台输出结果

var 模式输出: 3
var 模式输出: 3
var 模式输出: 3
IIFE 闭包输出: 0
IIFE 闭包输出: 1
IIFE 闭包输出: 2

在 var 模式下，所有的定时器回调函数共享同一个全局/函数级 i 变量；当定时器回调执行时，循环早已跑完，此时 i 为 3。而在 IIFE 模式中，每次循环都调用了一次匿名函数，为每一个定时器创建了专属的局部词法环境，锁定了当时的 lockedJ 参数。在现代 ES6 中，直接使用 let 声明循环变量本质上也是由引擎在每次循环迭代时创建独立块级词法环境来实现类似效果。

六、注意事项：闭包与“内存泄漏”的辩证认知

关于闭包，常能听到一种以讹传讹的论调：“闭包会导致内存泄漏，尽量不要用”。这种观点混淆了正常内存驻留与非预期内存泄漏的界限。

核心判断依据

内存驻留（合法使用）：业务确实需要长期保留某项状态（如防抖、节流、全局模块单例），闭包保留该环境是符合预期的设计，不叫内存泄漏。

内存泄漏（非预期残留）：某些闭包由于疏忽被挂载在全局对象、长期存活的事件监听器、未清理的定时器中，导致本不再使用的庞大数据对象无法被垃圾回收，这才是内存泄漏。

1. 如何主动释放闭包占用的内存

既然垃圾回收判定依据是“GC Roots 可达性”，那么释放闭包内存的方法非常简单直观：切断从根节点到闭包函数的引用即可。

function createHeavyTask() {
    let largeBuffer = new Array(1000000).fill("数据块");

    return function() {
        return largeBuffer.length;
    };
}

let taskRunner = createHeavyTask();
console.log("缓冲区长度:", taskRunner());

// 当确认不再需要该闭包时，显式解除引用
taskRunner = null;
// 此时 taskRunner 不再指向闭包函数，闭包函数与包含的 largeBuffer 失去可达性，在下次 GC 时被释放

控制台输出结果

缓冲区长度: 1000000