JavaScript作用域链到底怎么形成的？从词法作用域到闭包一次讲透

1. 作用域到底是什么：先把“变量去哪儿了”这件事讲透

我在面试别人的时候，几乎每次都会问一个摸底问题：“详细说说你对作用域和作用域链的理解”。问十个人里，大概有七八个能背出“作用域是变量的有效访问范围，作用域链是变量查找的链路”这种标准答案，但再追问一句“那作用域链到底是什么时候形成的”，一半人就卡住了。这个现象特别有意思——大家都觉得自己知道，实际上只是记住了概念的壳，没拿到内核。

作用域（Scope）本质上是一套规则，用来决定“当前代码能访问哪些变量”。你可以把它想象成一张通行证：你在哪个区域里，决定了你能进哪些门。JavaScript引擎在执行代码之前，会先做一遍完整的词法解析，把每一段代码里声明了哪些变量、这些变量归属于哪个区域，全部登记在案。这个阶段不执行任何逻辑，纯粹是“查户口”，登记完毕之后才开始真正跑代码。

很多人把作用域理解成一个“容器”，习惯说“变量在某个作用域里”。这个说法不算错，但容易误导。作用域其实是一种约束规则，它规定了：当你在某个位置写下一个变量名时，引擎应该去哪里找这个变量对应的值。至于“作用域链”，就是这套查找规则在嵌套结构下的具体路径。

这里有个关键点必须掰扯清楚：JavaScript采用的是静态作用域，也叫词法作用域。意思是，一个函数能访问哪些变量，在它被定义的那一刻就已经决定了，跟你这个函数在哪被调用没有任何关系。这是作用域链和 this 指向最大的区别——this 是动态绑定的，谁调用指向谁；作用域链是静态绑定的，定义在哪就指向哪。

我举个例子你就明白了：

javascript复制const a = 1;

function outer() {
  const b = 2;
  function inner() {
    console.log(a + b); // 3
  }
  return inner;
}

const fn = outer();
fn(); // 3

inner 定义在 outer 内部，所以它能同时访问到 outer 里的 b 和全局的 a。关键在于，哪怕我们把 inner 通过返回值带到了全局环境里执行，它依然认识自己的“出生地”，依然能找到 b。这就是词法作用域的含义——看代码结构就能推断出结果，不需要关心调用位置。

2. 全局、函数、块级：JavaScript的三种作用域类型

JavaScript的作用域类型经历过一个演变过程，从最早只有全局和函数两种，到后来补上了块级，这段历史直接影响了很多老代码的“怪异行为”，也解释了为什么现在面试特别喜欢考 var 和 let 的区别。

2.1 全局作用域：所有变量的默认归宿

在浏览器环境里，全局作用域的顶层对象是 window，在 Node.js 里是 global。在任何位置都能访问到的变量，就是全局变量。全局变量有两种常见来源：一种是在顶层用 var 或 function 声明的，另一种是根本没写声明关键字、直接赋值的。

后者是个大坑。在非严格模式下，给一个未声明的变量赋值，JavaScript会自动帮你把它挂到全局对象上。这意味着，你在某个函数内部随手写了个 count = 1，它就成了全局变量，全项目的任何地方都能改它。多人协作时这种代码简直就是定时炸弹。所以现在写代码，严格模式几乎是标配，至少能在第一步拦住这种隐式全局。

2.2 函数作用域：JavaScript最初的“局部”概念

ES6 之前，函数是JavaScript里唯一能创造局部作用域的结构。var 声明的变量，在函数内部就是局部的，出了函数谁也访问不到。但 var 有个著名的毛病——不存在块级作用域：

javascript复制if (true) {
  var leak = '我在外面也能访问到';
}
console.log(leak); // '我在外面也能访问到'

var 只看函数边界，花括号圈不住它。所以在早期代码里，for 循环里定义的循环变量，循环结束后依然活着，这不是bug，是设计如此。很多老前端写代码时必须刻意用函数去“包一层”，就是为了制造隔离。IIFE（立即执行函数表达式）在当年那么流行，根本原因就是当时只有函数能隔离作用域。

2.3 块级作用域：let/const带来的真正改变

ES6 引入了 let 和 const，块级作用域才正式登场。所谓块，就是一对花括号包起来的区域——if 分支、for 循环、while 循环，甚至单独的 {}，都能形成独立的变量空间。

javascript复制if (true) {
  let safe = '我在外面访问不到';
  const alsoSafe = '我也是';
}
console.log(safe);     // ReferenceError: safe is not defined
console.log(alsoSafe); // ReferenceError: alsoSafe is not defined

这个改动看起来不大，但对代码的健壮性影响深远。它让变量有了更精确的生命周期，也让 for 循环的闭包问题迎刃而解。至于具体怎么解决的，后面的循环陷阱部分再展开。

2.4 暂时性死区：块级作用域的“附加条件”

let 和 const 还有一个 var 没有的特性——暂时性死区（Temporal Dead Zone，TDZ）。以前用 var 的时候，变量声明会被提升（hoisting）到作用域顶部，初始化默认是 undefined，所以你在声明之前访问它，得到的只是 undefined，不会报错，但这种行为掩盖了很多逻辑问题。

let 和 const 也提升，但提升的是“绑定关系”，而不是初始化。在变量声明语句执行之前，这个变量处于“存在但不可访问”的死区状态，访问它会直接抛 ReferenceError：

javascript复制console.log(a); // ReferenceError: Cannot access 'a' before initialization
let a = 1;

很多初学者会疑惑：既然变量提升，为什么还能报错？答案是它提升了绑定，但没提升初始化。死区存在的意义，就是强制你“先声明，再使用”，从语言层面把这种错误暴露出来，而不是默默给你一个 undefined。这也是面试里区分“语法理解”和“机制理解”的经典考点。

3. 作用域链的形成机制：它是一条链，不是一棵树

接下来是整篇文章的重头戏：作用域链到底怎么形成的。很多资料把作用域链描述成“从内层往一层层向外查找变量”，这个描述本身没错，但它回答的是“查找过程”，而不是“形成过程”。你要真正理解作用域链，必须从JavaScript引擎的数据结构说起。

3.1 [[Environment]]：函数出生时就定好的“老家地址”

JavaScript引擎在解析阶段会给每个函数对象内部挂一个隐藏属性，规范里叫 [[Environment]]。这个属性存的是什么？是对“函数定义时所在词法环境”的一个引用。

什么叫词法环境？你可以把它简单地理解成“当前代码区域里所有变量和函数的注册表”。全局有全局词法环境，每个函数调用时会创建一个新的函数词法环境。关键点来了：[[Environment]] 是在函数定义时确定的，不是在调用时确定的。

javascript复制let x = 10;

function foo() {
  console.log(x);
}

function bar() {
  let x = 20;
  foo(); // 输出 10 还是 20？
}

bar(); // 输出 10

答案是 10。因为 foo 定义在全局环境下，它的 [[Environment]] 指向全局词法环境。bar 里的 x = 20 对 foo 完全不可见。这很反直觉，很多初学者以为“调用 foo 的地方在 bar 内部，应该能找到 bar 里的 x”。错了，作用域链从来不看调用位置，只看定义位置。

3.2 执行上下文、词法环境与外层引用：三者怎么串起来

函数每次被调用时，引擎会创建一个执行上下文，并为其关联一个全新的词法环境。这个词法环境里要装本地的变量、参数、函数声明，同时它还有一个重要的指针——outer，指向外层词法环境。这个 outer 的指向，就是拿函数的 [[Environment]] 来初始化的。

到这里，链路就清楚了：

1. 全局执行上下文创建全局词法环境。
2. 调用 foo 时，创建 foo 的执行上下文，新建词法环境。
3. 新词法环境的 outer 指向 foo.[[Environment]] 也就是定义时所在的词法环境。
4. 在 foo 内部访问一个变量时，先在自己词法环境里找，找不到就顺着 outer 往外层找，直到全局环境。

这条从“当前词法环境”一路通过 outer 指针串联到全局环境的路，就是作用域链。它本质上是结构化的链式引用，每次访问变量都等价于在这条链上做线性查找。

这也是为什么说“作用域链是静态的”——因为词法环境的嵌套结构在代码解析阶段就已经定死了，outer 的指向不会因为运行时的调用关系发生变化。

3.3 变量查找的完整过程：一步步顺着链条走

我拿一个三层嵌套的例子，完整走一遍查找流程：

javascript复制const globalVar = 'global';

function outer() {
  const outerVar = 'outer';
  
  function inner() {
    const innerVar = 'inner';
    console.log(innerVar);   // 1. 在当前词法环境找到
    console.log(outerVar);   // 2. 当前没有，去外层找到
    console.log(globalVar);  // 3. 再往外层，去全局找到
  }
  
  inner();
}

outer();

访问 innerVar 时，引擎在当前词法环境里直接命中，查找结束。访问 outerVar 时，当前环境没有，于是顺着 outer 指针跳到外层环境，找到了。访问 globalVar，又跳一层，在全局环境里命中。

这个查找过程就是作用域链的核心工作方式。理解了它，你就能解释一个经典事实：外部作用域无法访问内部作用域的变量，但内部作用域可以访问外部作用域的变量。

4. 闭包与作用域链：一体两面，面试官最爱追问的地方

如果说作用域链是JavaScript的骨架，闭包就是骨架之上最耀眼的血肉。这两个概念在面试里总是成双成对出现，原因很简单：没有作用域链，闭包就不存在。

4.1 闭包的本质：作用域链被“延长”后的结果

我见过很多解释闭包的说法：“函数内部返回一个函数”“内部函数持有外部函数的变量”。这些说法都对，但都只停留在现象描述。闭包的本质是：当一个函数被返回并在其定义时的词法环境之外执行时，它通过作用域链，依然保留着对该词法环境的引用能力。

核心机制就是前面说的 [[Environment]]。正常情况下，函数执行完毕，它的执行上下文和词法环境会被回收。但如果有内部函数被外部变量持有，这个内部函数的 [[Environment]] 还引用着外层函数的词法环境，那这个词法环境就不会被垃圾回收掉。于是外层函数的变量就这么被一直“保供”着。

javascript复制function createCounter() {
  let count = 0;
  return function() {
    count++;
    console.log(count);
  };
}

const counter = createCounter();
counter(); // 1
counter(); // 2
counter(); // 3

createCounter 执行完了，但返回值那个匿名函数还握着 count 的引用，所以 count 没有消失在垃圾回收里，而是继续存活。每次调用 counter，引擎通过作用域链找到 createCounter 的词法环境，在那里操作 count。

面试时你如果能把这个机制讲到“词法环境、[[Environment]]、垃圾回收的引用保全”这个粒度，基本就能让面试官眼前一亮了。

4.2 经典循环问题：var的锅还是作用域的锅？

作用域链和闭包结合最经典的一道面试题，就是 for 循环加 var 加 setTimeout：

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

很多解释都把锅甩给 var，说“因为 var 没有块级作用域”。为什么？

用作用域链的话来说是这样的：var i 是函数作用域，整个循环里只有一个 i，它的词法环境是当前函数环境（或者全局环境，这里就是全局环境）。循环每转一圈，setTimeout 的回调函数都闭包引用着同一个 i。循环结束后，i 的值变成了5，然后回调才开始执行，所有回调找到的都是同一个 i，所以输出5。

如果把 var 换成 let：

javascript复制for (let i = 0; i < 5; i++) {
  setTimeout(() => {
    console.log(i);
  }, 100);
}
// 输出 0 1 2 3 4

let 为每一轮循环都创建了一个独立的块级词法环境，每一轮都有自己的 i 副本。setTimeout 回调闭包捕获的是本轮独立的 i，所以每各回调各找各的，输出 0 到 4。

这个例子完美展现了作用域链的静态特性：闭包捕获的是“定义位置所在环境的变量”，而不是“某个同名变量的最终值”。理解了这个，比死记“let 解决闭包问题”高出一个段位。

5. 作用域链上的那些实战坑：遮蔽、性能与笔试陷阱

理论讲完了，说点实战里真正会遇到的问题。作用域链不是只活在面试题里的概念，日常开发中你对它的理解深浅，直接决定你能不能快速定位一类诡异的bug。

5.1 变量遮蔽：同名变量的优先级之争

在嵌套作用域里，内层声明的变量如果和外层同名，内层变量会“遮蔽”外层变量。查找变量时，引擎在当前作用域一旦找到目标，就直接返回，不再继续向外查找。

javascript复制let value = 'outer';

function test() {
  let value = 'inner';
  console.log(value); // 'inner'
}

test();

你在函数里写了个 let value，在当前作用域就能找到，作用域链的查找在第一步就结束了，外层的 value 压根没机会被看到。

这个机制带来一个很实际的坑：函数参数和内部变量同名。参数本质上也是函数词法环境里的变量，如果你在函数内再声明一个同名变量，后者会遮蔽前者，而且因为 var 的声明提升机制，还可能出现意外。

javascript复制function greet(name) {
  var name = 'world';
  console.log('Hello, ' + name);
}

greet('张三'); // Hello, world

这种代码可读性很差，ESLint 里甚至专门有 no-shadow 规则来禁止变量遮蔽。遇到这种情况，第一原则是给内层变量换个更具体的名字，不要偷懒。

5.2 深层作用域链对性能的影响：真的需要担心吗？

既然作用域链是外层查找，那层级越深，查找链路越长，理论上性能损耗就越大。早期JavaScript引擎的确存在这个问题，所以老一代前端会有一个经验：在函数开头把全局变量存成本地变量，缩短作用域链的查找路径。

javascript复制let a = 1;
let b = 2;
let c = 3;

// 不推荐的写法
function sum1() {
  return a + b + c; // 每次访问都要走三层查找
}

// 推荐的老式优化写法
function sum2() {
  const a1 = a, b1 = b, c1 = c;
  return a1 + b1 + c1; // 本地变量，一步到位
}

但是，现代的 V8 引擎早就不是当年的引擎了。V8 有内联缓存（Inline Caches）优化，同一段代码反复执行时，对于某个位置的变量查找，引擎会记住上次的查找结果，直接拿到对应的词法环境，基本不会每次都从头遍历链条。所以现在很少有人再为了性能做这种手动局部化优化了。

我的建议是：把优化重点放在可读性上，而不是假设引擎很蠢。 当然，如果你是写那种每帧执行上千次的热路径代码，把高频访问的变量存成局部变量依然是有意义的，但这事儿要基于性能分析结果去做，别凭空自我感动。

5.3 几道高频笔试题的逐步推导

笔试里作用域链相关题目翻来覆去就那么几道，我把最常见的两个拿出来，按引擎的查找流程推一遍，你看完自己就能举一反三。

第一道，经典中的经典：

javascript复制var num = 10;

function getNum() {
  console.log(num);
}

function showNum() {
  var num = 20;
  getNum();
}

showNum(); // 输出多少？

推导：getNum 定义在全局，所以它的 [[Environment]] 指向全局环境。调用 showNum 时，它的环境有自己的 num=20。但是 getNum 不被 showNum 的词法环境捕获——getNum 定义时跟 showNum 内部环境没有任何关系。所以 getNum 内部执行时，作用域链是“自身环境 -> 全局环境”，在全局找到了 num=10。输出10。这道题完美验证定义位置决定作用域链。

第二道，变量提升和时间死区的混合体：

javascript复制var a = 1;

function foo() {
  console.log(a);
  let a = 2;
}

foo(); // 会报什么？

推导：函数内部出现了 let a，所以在 foo 的词法环境里，a 这个变量的绑定从函数开始执行时就已经存在（但不是可访问）。执行到 console.log(a) 时，引擎在 foo 环境里找到了 a 的绑定，但此时它处于暂时性死区，访问直接抛错：ReferenceError: Cannot access 'a' before initialization。注意，这里不是找不到 a，而是找到了但不可用。引擎不会因为当前环境里有个死区变量就跳过它去外面找，这跟“没找到就向外”的规则不一样。

这两道题正好覆盖了作用域链查找的两个边界：链的起点看定义位置，当前环境的遮蔽优先于外层查找。

6. 顺便聊聊“bean的作用域”：Java和JavaScript的对照参考

既然最近“bean的作用域”这个话题热度不低，我也多说两句，正好拿来跟JavaScript的作用域做一次对照，能帮你以后阅读不同语言代码时不至于概念混淆。

Java（特别是Spring框架）里讲的“Bean作用域”，指的是Spring容器管理的对象实例的存活范围。常见的有几种：singleton（单例，容器启动创建一个实例，全局共享）、prototype（每次获取创建一个新实例）、request（每个HTTP请求一个实例）、session（每个会话一个实例）等等。它解决的是“这个对象该共享还是该独立”的问题，属于容器层面的生命周期管理。

JavaScript的作用域解决的是“这个变量在哪些代码区域可见”的问题，属于语言语法层面的可见性规则。两者虽然都叫 scope，但完全是两回事：

放在一起看反而更容易理解：JavaScript的作用域是“代码组织方式决定的自然规则”，Java Bean的作用域是“框架层面的配置决策”。面试时如果被问到这个对比，你能清楚说出两者的区别，说明你对作用域的理解已经超越了背概念的层面。当然，你要是只做前端，Bean作用域了解概念即可，不用深入。但JavaScript的作用域链和闭包，是必须吃透的。

7. 最后分享一条实际经验：面试时怎么答这道题

这个标题本身就是一道面试题，我最后以“被面者”和“面试官”的双重身份，说说这类题目到底该怎么答。

很多人的回答是：“作用域是变量的有效范围，作用域链是由内到外的变量查找链。”这句话只能得60分，因为它只是名词解释，没有展示出你对机制的理解深度。想拿高分，按这个结构组织你的回答：

第一步，说清作用域的本质：一套词法层面的规则，决定变量在哪里可见、引擎去哪儿找它。顺带提一句静态作用域（词法作用域），强调定义位置决定一切，调用位置不参与。

第二步，列出JavaScript的三种作用域类型：全局、函数、块级，并说明 var 与 let/const 的关键差异，提一下暂时性死区。

第三步，讲作用域链的机制：函数对象在定义时持有 [[Environment]] 引用，函数调用时创建词法环境，新环境通过 outer 指针指向上层环境，层与层之间串成链条。变量查找就是在这条链上做逐层检索。

第四步，用闭包收尾：闭包不是魔法，就是作用域链延长的产物，外部函数执行完后，内部函数通过链还能访问到外层词法环境中的变量。经典循环题、防抖节流、模块化封装，全都是这个机制的实际应用。

我面试过不少人，能把这个结构讲完整的候选人，哪怕代码写得一般，我也愿意给机会。因为这说明他不是背题，而是真的能理解JavaScript这门语言的执行模型。反过来，你在日常开发中遇到诡异bug时，多往作用域链、执行上下文这个方向想想，很多问题自己就通了。