JavaScript作用域与作用域链：从执行上下文到闭包的底层原理与实战指南

作用域和作用域链，这两个词对于写 JavaScript 的人来说，基本属于“面试必问，工作必用”的级别。但说实话，我在面试候选人时，很多人能背出“作用域是变量可访问的范围，作用域链是嵌套作用域的分层查找机制”这种标准定义，可真扔给他们一段有坑的代码，能准确分析出执行过程和输出结果的人，其实不到一半。这说明什么？说明很多人对这个概念的理解停留在“死记硬背”，而没有真正建立起一套动态的、可推演的思维模型。

这篇文章我不想掉书袋，我想从一个实际开发者的视角，把作用域和作用域链彻底掰开揉碎了讲清楚。不光是理论，更重要的是搞明白它们底层是怎么运转的，为什么这么设计，以及在实际项目中我们怎么利用它写出更健壮、更优雅的代码。本文适合刚入门想要夯实基础的新人，也适合工作两三年想系统梳理一遍的同学，哪怕是资深工程师，当成一次查漏补缺的复习也够格。

我会从作用域的类型演进讲到作用域链的查找机制，从底层实现（执行上下文、词法环境）讲到上层应用（闭包、变量提升、IIFE），最后再结合相关热词“bean的作用域”做一次跨语言对比。这内容全写下来信息量不小，但对理解 JavaScript 整个执行模型会是一次完整的扫盲。

1. 作用域：不只是“变量的访问范围”这么简单

1.1 为什么需要作用域？先解决变量冲突的噩梦

先说一个最朴素的问题：为什么语言设计者要发明“作用域”这个东西？答案很简单，没有作用域，所有变量都得活在同一个全局命名空间里，那简直就是一场灾难。

你想想看，如果你的项目里有100个文件，每个文件里都顺手定义了一个 let data，没有作用域隔离的情况下，后定义的就直接把前面定义的覆盖了。模块之间稍有不慎就会互相污染，代码根本没法维护。

作用域的本质，就是给变量划定“合法活动区域”。一个变量定义在哪个作用域，它就只能在这个作用域及内层嵌套的区域内被访问。外部的代码看不见它，当然也就改不了它，这就天然形成了一道隔离墙。

我习惯用“房间”来类比作用域：每一个作用域就像一栋楼里的一个房间，房间里摆着各种东西（变量）。你在房间里可以随便用自己房间里的东西，也能去更外层的公共区域拿东西，但你把东西放在自己房间里，外面的人是看不到的，不经邀请也进不来。这种隔离设计，让大型项目的代码协作成为可能。

1.2 JavaScript 的三类作用域：全局、函数、块级，一个都不能少

JavaScript 的作用域体系，经历了从 ES5 到 ES6 的演进后，形成了今天的格局：全局作用域、函数作用域、块级作用域。三种各司其职，覆盖了不同粒度的变量隔离需求。

先看全局作用域。在最外层定义的变量、或者未通过 var/let/const 声明而直接赋值的变量（非严格模式下），都属于全局作用域。它们在页面或程序启动时就创建，程序结束才销毁。全局作用域的变量在任何地方都能访问到，这就是为什么 window 上的属性和方法随处可用。但全局变量也是风险源，滥用会导致命名冲突，而且不利于垃圾回收，能少用就少用。

再看函数作用域。在函数内部用 var 声明的变量，其可见范围就是这个函数体。出函数就访问不到了。function foo() { var a = 1; } console.log(a); // ReferenceError，这就是函数作用域在起作用。它是最经典的隔离机制，ES5时代全靠它支撑模块封装。函数作用域有个特点：外层访问不到内层，但内层可以顺着作用域链访问外层，这种“内层可见外层，外层不见内层”的方向性，是整个作用域体系的根本规则。

最后是块级作用域，这是 ES6 引入 let 和 const 之后才正式有的。块级作用域的范围是 {} 包围的代码块，比如 if 块、for 块等。let 和 const 声明的变量只在当前块内生效。很多人对块级作用域最直观的感受，来自于 for 循环经典面试题——也就是那个“var 还是 let”的问题。我们先按下不表，后面实操部分会重点展开。

把三类作用域放在一起，它们就构成了一个嵌套的体系。最外层是全局，往里是函数，再往内可能还有块级。每一层都有一份属于自己的变量“目录”，代码执行时需要通过一套规则去查找“目录”中的名字，这套规则的核心，就是作用域链。

2. 作用域链：从房内到整栋楼的变量查找路线图

2.1 作用域链的构建时机与查值规则

作用域链不是在代码运行到某一行时才临时“画”出来的，它是在函数定义的时候，就根据代码的嵌套结构预先形成的。这一点非常重要，也是初学者最容易理解偏的地方。

先记住一个核心规则：作用域链的静态结构取决于函数定义的位置，而不是函数的调用位置。这个规则在 JavaScript 中有一个专门术语叫“词法作用域”（Lexical Scoping）。

举个例子：

javascript复制var globalVar = '全局变量';

function outer() {
    var outerVar = '外部变量';
    
    function inner() {
        var innerVar = '内部变量';
        console.log(innerVar);   // 内部变量
        console.log(outerVar);   // 外部变量
        console.log(globalVar);  // 全局变量
    }
    
    inner();
}

outer();

inner 函数定义在 outer 内部，所以它的作用域链从内到外是：inner 作用域 → outer 作用域 → 全局作用域。当 inner 内部访问 outerVar 时，JS 引擎先在 inner 自己的变量里找，找不到就往上一层 outer 作用域里找，再找不到就去全局找。这条查找路径，就是作用域链。

这个机制非常像我们在一栋办公楼里找某个房间的共享设备：先在当前办公室找，找不到就上楼层管理处问，再找不到就去物业总台查询。路径是固定好的，每层楼都只有一条向上通道，不存在“跨层直达”或者“往下访问内部房间”的情况。

2.2 深度解析查找过程：每个变量名都要走一遍链路

为了把查找过程讲得够透，我再举一个真实的案例分析一下。这段代码是我之前调试过的比较典型的嵌套场景：

javascript复制var nickname = '阿强';

function boot() {
    var level = 3;
    
    function config() {
        var api = '/api/v1';
        console.log(level);       // 3，当前作用域没有，向上一级 boot 作用域找到
        console.log(nickname);    // '阿强'，当前没有，boot 也没有，再到全局找到
    }
    
    function report() {
        var level = 5;  // 注意这里声明了同名变量
        console.log(level);       // 5，当前作用域直接命中，不会去 boot 里找
        console.log(api);         // ReferenceError! 当前没有，boot 也没有，全局也没有
    }
    
    config();
    report();
}

boot();

这个例子揭示了两个重要结论。第一，作用域链的查找优先级是“就近原则”，当前作用域如果有同名变量，直接使用，绝不会额外往上层跑。第二，平级作用域之间是不通的。config 和 report 是同级的两个函数，config 里定义了 api，report 里访问 api 时，它沿着自己的作用域链去找：report 作用域 → boot 函数作用域 → 全局作用域，都找不到，直接报 ReferenceError。它完全不知道也不关心旁边还有一个 config 作用域里藏着 api。

很多人在模块化协作的时候会踩这个坑，以为同级的兄弟函数定义的变量另一个也能用，其实它们的“可见关系”是纵向的（父子嵌套），不是横向的（平行兄弟）。这个认知如果不对，调 bug 的时候就会发现浏览器控制台各种 ReferenceError 满天飞，排查半天下不来。

2.3 闭包：利用作用域链保留“过去的环境”

讲透了作用域链，闭包就是一个顺理成章的推论了。闭包的本质，就是“函数 + 它在定义时捕获的外部作用域引用”。因为作用域链的存在，一个内层函数即使在外层函数执行完毕之后，仍然能访问到外层函数的变量。

原因是外层函数的变量虽然属于函数作用域，但只要还有内部函数引用着这条作用域链，这些变量就不会被垃圾回收机制清理。

javascript复制function counterStep(step) {
    var count = 0;
    return function () {
        count += step;
        return count;
    };
}

var step2 = counterStep(2);
var step5 = counterStep(5);

console.log(step2()); // 2
console.log(step2()); // 4
console.log(step5()); // 5
console.log(step5()); // 10

这里 step2 和 step5 各自捕获了不同的 count 和不同的 step 环境。两个函数虽然都是同一次工厂生产出来的，但它们的作用域链上绑定的“环境记录”是独立的两份。这就是闭包最经典的工厂模式应用，在实际项目中做计数器、做防抖节流、做 React 的 useCallback 底层逻辑时，本质上都是这个套路。

不过闭包也是一把双刃剑，因为它会阻止垃圾回收，所以处理不好就会造成内存泄漏。我在做前端性能优化时排查过好几次这样的问题，DOM 元素已经移除了，但事件处理函数还引用着外层对象，导致整个数据区都无法被回收。后面我会在常见问题里专门整理这个坑。

3. 底层原理：执行上下文与词法环境到底怎么配合

3.1 从“静态规则”到“动态环境”的转换

作用域链给我们的是一种“静态的嵌套关系”图，但代码真正跑起来时，JavaScript 引擎需要把这个静态关系实例化成一套可执行的数据结构，这就是执行上下文（Execution Context）和词法环境（Lexical Environment）。

可以这样理解：作用域链是图纸，规定了你家房子哪些区域归谁，而执行上下文是“实际入住的你”，你每次进入一个房间（调用一个函数、进入一个块），都会按图纸把家具（变量、函数声明）搬进去布置好，这个过程就可以理解为创建词法环境。

执行上下文栈是引擎当前正在执行的位置的记录。全局代码开始执行时，先压入全局执行上下文。每次调用一个函数，就往栈里压入一个新的函数执行上下文。函数运行完毕，上下文出栈销毁。栈最顶上那个上下文，就是当前正在执行的代码所在的环境。

3.2 词法环境的组成：环境记录 + 外部引用

一个词法环境由两部分组成：环境记录（存储当前作用域的变量和函数声明）和对外部词法环境的引用（指向外层作用域的词法环境）。

JavaScript 引擎在查找变量时，本质上就是拿着名字在当前环境记录里找，找不到就走“外部引用”找到外层词法环境，再到那层的环境记录里找。这跟我们前面描述的作用域链查找规则是逐字匹配的。换句话说，词法环境就是作用域链在运行时的物理载体。

举一个典型的现场，看看 var 和 let 在词法环境里的区别：

javascript复制function example() {
    console.log(a); // undefined，不会报错
    console.log(b); // ReferenceError: Cannot access 'b' before initialization

    var a = 1;
    let b = 2;
}

因为 var 声明的变量在环境创建阶段就初始化了，默认值为 undefined，所以虽然“提升了”，但没有值。let 声明的变量在创建阶段同样存在于环境中，但它处于“暂时性死区”（TDZ, Temporal Dead Zone），从代码执行进入这个作用域开始，直到声明语句真正执行之前，访问它都会抛错。这就是为什么 console.log(a) 不报错而 console.log(b) 会报错。理解这一层，SDK 开发时对代码初始阶段访问变量的判断就能少踩很多坑。

3.3 函数定义与函数调用两种维度的环境记忆

很多人会把“变量环境”和“词法环境”搞混。在 ES6 之前，执行上下文里只有一个变量环境，所有 var 和函数声明都放这里。ES6 之后，新增了词法环境来存放 let 和 const 声明的变量，两个环境并存，配合完成作用域的管理。

在实际执行过程中，“函数定义”和“函数调用”会各自留下一笔记录。定义时留下的是外层词法环境引用，调用时创建的是新的执行上下文。每次函数调用，即使函数体完全一样，也会生成一个全新的执行上下文和全新的词法环境，彼此互不干扰。这也是递归函数能正常工作的底层保障——每一次递归都不污染上一次的局部变量。

这里我给一个底层数据结构的伪代码来描述词法环境，方便有后端基础的读者理解：

javascript复制// 伪代码：词法环境的内部结构
LexicalEnvironment = {
    EnvironmentRecord: {
        // 存放当前作用域内 var 声明、函数声明、let/const 声明
        // 例如：type: "Object" | "Declarative"
        // 实际是键值对 { 变量名: 值 }
    },
    Outer: LexicalEnvironmentReference // 指向外层词法环境，或者 null（全局环境为 null）
}

实际引擎的实现（V8）会比这个抽象模型复杂得多，涉及隐藏类和内联缓存等优化机制，但抽象模型完全够我们进行逻辑推演。遇到任何作用域相关的代码分析题，把这个三层结构画出来，答案基本就浮出水面了。

4. 实操：经典代码场景中的作用域链推演

4.1 场景一：for 循环中的 var 陷阱与 let 的救赎

这是前端面试最高频的场景，也是实际开发中最常遇到的 bug 来源。看这段代码：

javascript复制// 场景 A：var 声明
for (var i = 0; i < 5; i++) {
    setTimeout(function () {
        console.log(i); // 输出：5 5 5 5 5
    }, 1000);
}

// 场景 B：let 声明
for (let j = 0; j < 5; j++) {
    setTimeout(function () {
        console.log(j); // 输出：0 1 2 3 4
    }, 1000);
}

场景 A 为什么全是 5？因为 var i 是在函数作用域级别声明的，整个 for 循环所在的函数（或者全局）范围内只有一份 i 变量。循环跑了 5 次，i 最终停在了 5。一秒后定时器回调执行，顺着作用域链找 i，找到的就是那个共享的、已经等于 5 的变量。

场景 B 为什么正常？因为每次循环迭代，let j 都会为这个迭代块创建一份全新的词法环境，每次迭代的 j 都被绑定在当前的块级作用域中。定时器回调捕获的是各自的块级环境，所以每个回调找到的是独立的 j。

这个知识点不仅是面试题，也是日常写代码必须养成的习惯。如果你还在用 var 写 for 循环并在循环体里注册异步回调，那大概率已经埋下了 bug 的种子。

4.2 场景二：立即执行函数 IIFE 在 ES5 时代如何模拟块级作用域

在 let 还没普及的年代，前端老前辈们为了达到“绑定每次循环的独立值”的效果，使用的优雅方案就是 IIFE（Immediately Invoked Function Expression）。IIFE 创造了一个独立的函数作用域，把循环变量作为参数传进去，每次迭代就复制了一份值。

javascript复制// ES5 时代的经典写法
for (var i = 0; i < 5; i++) {
    (function (idx) {
        setTimeout(function () {
            console.log(idx);
        }, 1000);
    })(i);
}

这里关键是函数参数 idx 属于函数作用域的局部变量，每次调用 IIFE 都会创建一个新的执行上下文，idx 是当前迭代值的一份拷贝。内部定时器回调作用域链找到的是那个独立的 idx，而不是循环变量 i。这套逻辑即使在今天的现代开发中，也能在很多源码库的兼容层代码里见到，看懂它，对理解 ES5 到 ES6 的演进脉络有很大帮助。

4.3 场景三：事件批量绑定与数据回显的坑

再分享一个我实际项目里踩过的坑。做一个表格批量操作功能，为每一行的“编辑”按钮绑定点击事件，需要把行数据 id 传到事件处理函数中：

javascript复制// 错误示范：全部输出最后一行的 id
var editButtons = document.querySelectorAll('.edit-btn');
for (var i = 0; i < editButtons.length; i++) {
    editButtons[i].addEventListener('click', function () {
        var id = rowDataList[i].id; // i 是共享的那个
        openEditDialog(id);
    });
}

// 正确示范：用 let 绑定每一次迭代
for (let k = 0; k < editButtons.length; k++) {
    editButtons[k].addEventListener('click', function () {
        var id = rowDataList[k].id;
        openEditDialog(id);
    });
}

错误案例的表现就是：点任何一行按钮，打开的编辑框永远是最后一行的数据。原因并不复杂，所有事件回调共享同一个 i，当时 i 已经是最后一行的索引了。这个 bug 的特征非常具有迷惑性，因为代码逻辑看起来对，但行为就是诡异。排查时只需要把 var 改成 let，或者用 data-id 属性存值，就能丝滑解决。我现在写批量事件绑定的代码，要么用 let，要么直接把 id 挂在 dataset 上，彻底避开这类问题的死角。

4.4 场景四：函数声明提升与 var 提升的优先级

最后一个实操场景，来看一个容易踩坑的函数与变量提升优先级问题：

javascript复制function hoistTest() {
    console.log(foo); // ƒ foo() { return 'function'; }

    var foo = 'variable';
    function foo() {
        return 'function';
    }

    console.log(foo); // 'variable'
}

hoistTest();

第一次打印 foo 输出函数，而不是 undefined，这个细节非常有意思。ES 规范规定，在执行上下文创建阶段，函数声明会被完整加入环境记录并初始化；而 var 声明的变量，如果与函数同名，则“让位”给函数声明。

等到真正执行到 var foo = 'variable' 这行代码时，函数环境的变量值被重新赋值为字符串 'variable'。所以第二次打印变成了 'variable'。

这个行为在实际业务代码中可能引起非常难排查的隐性 bug，尤其是当你在某个作用域内同时定义同名函数和同名变量时，代码的可读性会被严重破坏。我的建议是：永远不要主动依赖“提升”特性，声明变量就用 let/const，函数就用普通函数声明或箭头函数常量，保持作用域内的命名唯一性。代码顺不顺手，很多习惯都是从小处积累的。

5. 扩展认知：从 JavaScript 作用域联想到 Spring Bean 的作用域

既然现在网络上“bean的作用域”这个话题热度很高，我也来凑个热闹，把 JavaScript 的作用域和 Java Spring 框架中 Bean 的作用域放在一起对比一下。很多人一开始容易把这两个概念搞混，因为它们都叫“作用域”，所处的层面和应用场景却完全不同。

Spring 框架中 Bean 的作用域，解决的是“对象实例创建之后，它存活多长时间、被哪些地方共享”的问题。典型的 Spring 作用域包括：

• singleton，默认值，整个容器中只创建一个 Bean 实例，所有注入的地方共享同一个对象。
• prototype，每次获取或注入时都创建一个新实例。
• request，每个 HTTP 请求一个实例。
• session，每个 HTTP 会话一个实例。
• application，整个 ServletContext 一个实例。
• websocket，整个 WebSocket 会话一个实例。

JavaScript 的作用域则是在语言引擎层面，定义“变量名在什么代码区域内可被解析到”，管理的是标识符的可见性。两者不在同一个维度上：一个是对象生命周期与共享策略，另一个是变量绑定规则的静态结构。

不过它们也有相似的设计哲学：都是为了隔离和控制。Spring 用不同的 Bean 作用域来控制对象在并发环境下的共享程度，避免多线程环境下的资源竞争和无状态冲突；JavaScript 用不同层级的作用域来控制变量名的可访问范围，避免命名空间污染和数据异常修改。两种“作用域”都在各自生态里承担着“边界守卫”的角色。

了解了这个概念差异，在跨语言协作的技术讨论中就不会再把它们混为一谈。如果你以前端为主、偶尔写写 Java 接口，把这个区分记清楚，面试官问到的时候能展示出非常扎实的基础功底。

6. 实战检查清单：判断一段代码中作用域链的关键步骤

给出一段代码，如何快速准确地分析变量输出结果？我总结了一套方法论，个人觉得非常实用，无论是刷题还是调试，都可以按这个顺序走：

第一步，先把代码中声明的所有函数用“定义时所在的嵌套层级”画出来，确定每个函数的外层词法环境是谁。这是静态分析，跟函数是否被调用无关。

第二步，从最内层的执行上下文开始，列出当前作用域内的所有变量声明，包括 var、function、let、const，区分哪些已经被初始化，哪些还在 TDZ 状态。

第三步，遇到变量访问语句时，从当前环境记录开始逐层向外找，每一层先查自己的环境记录，查不到再通过 Outer 引用跳转，直到全局环境。如果全局都没有，就是 ReferenceError。

第四步，特别注意同名的遮蔽问题。当前层有变量就立刻采用，不再向上查找；但赋值操作需要确认变量是否存在，否则非严格模式下会意外创建全局变量，严格模式会直接抛错。

第五步，考虑异步回调的情况。定时器、Promise、事件回调里的代码，执行时机往往发生在外层同步代码结束后，这时候外层循环变量可能已经发生变化，需要提前预判作用域链上“捕获”的到底是什么。

这一套下来，绝大部分作用域相关的代码题都在掌控之中。我经常在团队分享时教组内新人这套“五步分析法”，他们普遍反馈比死记结论有效得多。

7. 高频问题与避坑经验：我可以直接“抄作业”的笔记

7.1 闭包导致内存泄漏怎么定位和处理

闭包正常使用没问题，但如果长期存活的数据结构持有大量 DOM 引用或不需要再使用的对象引用，就会造成内存只增不减。我之前排查过一次长时间运行的页面，内存占用从 60M 慢慢攀升到 1.2G。侦查手段是打开 Chrome DevTools 的 Memory 面板做堆快照对比，发现大量分离的 DOM 节点被 keydown 事件处理函数闭包引用着。

处理方案是：在添加事件监听器时，如果预期不会长期使用，就给监听器一个具名函数，并在合适时机用 removeEventListener 解绑；对不再使用的引用显式置为 null。在 React 等框架环境里，则要格外小心 useEffect 的清理函数是否完整，副作用函数中创建的闭包是否随着组件卸载被释放。

7.2 全局变量污染其实防不胜防

非严格模式下，如果给一个未声明的变量直接赋值，这个变量会被静默创建为全局变量：

javascript复制function foo() {
    // 没有声明就直接赋值
    total = 100;
}
foo();
console.log(total); // 100，跑到全局去了！

这在团队协作中是最隐蔽的坑之一。比如某个工具函数内部把 index 误写成了 inndex，代码不会报错，但会在全局创建了一个多余变量，如果恰好和别人的全局变量重名，就可能覆盖掉对方的逻辑。想要彻底杜绝这种问题，必须在所有源码文件开头加上 'use strict'，或者通过构建工具在编译阶段自动注入。我平时写库代码，严格模式是底线，这是保护自己也保护用户。

7.3 暂时性死区其实是为了安全性

有很多人对 let 和 const 的 TDZ 机制有抱怨，觉得“为什么 var 都能提升而 let 不行，检查起来太麻烦”。但实际上 TDZ 带来的好处非常明显：它强制开发者在变量声明之前不得使用该变量，这是在代码层面提前消灭了“先使用后声明”这种反人类逻辑。

这不是限制，而是语言在设计上对开发者的保护。ES6 之后的新代码中，我用 let 和 const 替代 var 的比例几乎到了 100%，从不依赖 var 的提升行为。这样代码的可预测性大幅提升，排错成本也直线下降。

7.4 对象属性加载的坑

对象属性和普通变量走的是不同的查找机制。作用域链只负责查找标识符（变量名），而对象属性访问走的是原型链。很多初学者会把两者搞混，比如：

javascript复制function Person(name) {
    this.name = name;
}
Person.prototype.getName = function () {
    return this.name;
};

var p = new Person('张三');
console.log(p.name);       // 属性访问走原型链
console.log(name);         // 全局变量访问走作用域链，和对象属性无关

弄清对象属性和作用域链的边界，在排查 undefined 或 ReferenceError 时会少走很多弯路。两者都会查找，但查找的主体、路径、目标都完全不同。

8. 一些体会，分享一下

学习作用域链，核心不是背概念，而是在脑子里建立起一套“代码的词法嵌套关系 → 执行时环境实例 → 逐层查值”的推演模型。我看过很多刚入行的同学，遇到复杂的闭包题全靠猜，猜对了也解释不出所以然；但一旦悟出这套分析模型，再看任何 JavaScript 执行相关的代码，思路都会清晰很多。

另外非常建议大家用 Node.js 或 Chrome 的调试工具，在源码位置打断点，然后看右侧 Scope 面板，那里会直接显示当前作用域的变量列表，以及函数闭包捕获了什么。一边打断点，一边对照本文提到的概念，很快就能把纸面上的知识变成肌肉记忆。

真正把作用域和作用域链吃透以后，你会发现不仅写代码更有底气，读框架源码（比如 React、Vue、Webpack 的这些内部实现）也会轻松很多，因为高级编程技巧的底层，往往都是对 JavaScript 作用域机制的精妙运用。希望这篇文章能成为你理顺这套知识体系的垫脚石。