你不懂JS：作用域与闭包第一章：什么是作用域？

港控/mmm° 2022-07-14 13:21 147阅读 0赞

几乎所有语言的最基础模型之一就是在变量中存储值，并且在稍后取出或修改这些值的能力。事实上，在变量中存储值和取出值的能力，给程序赋予了 *状态*。

如果没有这样的概念，一个程序虽然可以执行一些任务，但是它们将会受到极大的限制而且不会非常有趣。

但是在我们的程序中纳入变量，引出了我们现在将要解决的最有趣的问题：这些变量 *存活* 在哪里？换句话说，它们被存储在哪儿？而且，最重要的是，我们的程序如何在需要它们的时候找到它们？

回答这些问题需要一组明确定义的规则，它定义如何在某些位置存储变量，以及如何在稍后找到这些变量。我们称这组规则为：*作用域*。

但是，这些 *作用域* 规则是在哪里，如何被设置的？

## 编译器理论 ##

根据你与各种编程语言打交道的水平不同，这也许是不证自明的，或者这也许令人吃惊，尽管JavaScript一般被划分到“动态”或者“解释型”语言的范畴，但是其实它是一个编译型语言。它 *不是* 像许多传统意义上的编译型语言那样预先被编译好，编译的结果也不能在各种不同的分布式系统间移植。

但是无论如何，JavaScript引擎在实施许多与传统的语言编译器相同的步骤，虽然是以一种我们平常不能发觉的更精巧的方式。

在传统的编译型语言处理中，一块儿源代码，你的程序，在它被执行 *之前* 典型地将会经历三个步骤，大致被称为“编译”：

1.  **分词/词法分析：** 将一连串字符打断成（对于语言来说）有意义的片段，称为token（记号）。举例来说，考虑这段程序：`var a = 2;`。这段程序很可能会被打断成如下token：`var`，`a`，`=`，`2`，和`;`。空格也许会被保留为一个token，这要看它是否是有意义的。
    
    **注意：** 分词和词法分析之间的区别是微妙和学术上的，其中心在于这些token是否以 *无状态* 或 *有状态* 的方式被识别。简而言之，如果分词器去调用有状态的解析规则来弄清`a`是否应当被考虑为一个不同的token，还是只是其他token的一部分，那么这就是 **词法分析**。
2.  **解析：** 将一个token的流（数组）转换为一个嵌套元素的树，它总体上表示了程序的语法结构。这棵树称为“AST”（**A**bstract **S**yntax **T**ree —— 抽象语法树）。
    
    `var a = 2;`的树也许开始于称为`VariableDeclaration`（变量声明）顶层节点，带有一个称为`Identifier`（标识符）的子节点（它的值为`a`），和另一个称为`AssignmentExpression`（赋值表达式）的子节点，而这个子节点本身带有一个称为`NumericLiteral`（数字字面量）的子节点（它的值为`2`）。
3.  **代码生成：** 这个处理将AST转换为可执行的代码。这一部分将根据语言，它的目标平台等因素有很大的不同。
    
    所以，与其深陷细节，我们不如笼统地说，有一种方法将我们上面描述的`var a = 2;`的AST转换为机器指令，来实际上 *创建* 一个称为`a`的变量（包括分配内存等等），然后在`a`中存入一个值。
    
    **注意：** 引擎如何管理系统资源的细节远比我们要挖掘的东西深刻，所以我们将理所当然地认为引擎有能力按其需要创建和存储变量。

和大多数其他语言的编译器一样，JavaScript引擎要比这区区三步复杂太多了。例如，在解析和代码生成的处理中，一定会存在优化执行效率的步骤，包括压缩冗余元素，等等。

所以，我在此描绘的只是大框架。但是我想你很快就会明白为什么我们涵盖的这些细节是重要的，虽然是在很高的层次上。

其一，JavaScript引擎没有（像其他语言的编译器那样）大把的时间去优化，因为JavaScript的编译和其他语言不同，不是提前发生在一个编译的步骤中。

对JavaScript来说，在许多情况下，编译发生在代码被执行前的仅仅几微妙之内（或更少！）。为了确保最快的性能，JS引擎将使用所有的招数（比如JIT，它可以懒编译甚至是热编译，等等），而这远超出了我们的关于“作用域”的讨论。

为了简单起见，我们可以说，任何JavaScript代码段在它执行之前（通常是 *刚好* 在它执行之前！）都必须被编译。所以，JS编译器将把程序`var a = 2;`拿过来，并首先编译它，然后准备运行它，通常是立即的。

## 理解作用域 ##

我们将采用的学习作用域的方法，是将这个处理过程想象为一场对话。但是，*谁* 在进行这场对话呢？

### 演员 ###

让我们见一见处理程序`var a = 2;`时进行互动的演员吧，这样我们就能理解稍后将要听到的它们的对话：

1.  *引擎*：负责从始至终的编译和执行我们的JavaScript程序。
2.  *编译器*：*引擎* 的朋友之一；处理所有的解析和代码生成的重活儿（见前一节）。
3.  *作用域*：*引擎* 的另一个朋友；收集并维护一张所有被声明的标识符（变量）的列表，并对当前执行中的代码如何访问这些变量强制实施一组严格的规则。

为了 *全面理解* JavaScript是如何工作的，你需要开始像 *引擎*（和它的朋友们）那样 *思考*，问它们问的问题，并像它们一样回答。

### 反复 ###

当你看到程序`var a = 2;`时，你很可能认为它是一个语句。但这不是我们的新朋友 *引擎* 所看到的。事实上，*引擎* 看到两个不同的语句，一个是 *编译器* 将在编译期间处理的，一个是 *引擎* 将在执行期间处理的。

那么，然我们来分析 *引擎* 和它的朋友们将如何处理程序`var a = 2;`。

*编译器* 将对这个程序做的第一件事情，是进行词法分析来将它分解为一系列token，然后这些token被解析为一棵树。但是当 *编译器* 到了代码生成阶段时，它会以一种与我们可能想象的不同的方式来对待这段程序。

一个合理的假设是，*编译器* 将会产生可以用这种假想代码概括的代码：“为一个变量分配内存，将它标记为`a`，然后将值`2`贴在这个变量里”。不幸的是，这不是十分准确。

*编译器* 将会这样处理：

1.  遇到`var a`，*编译器* 让 *作用域* 去查看对于这个特定的作用域集合，变量`a`是否已经存在了。如果是，*编译器* 就忽略这个声明并继续前进。否则，*编译器* 就让 *作用域* 去为这个作用域集合声明一个称为`a`的新变量。
2.  然后 *编译器* 为 *引擎* 生成稍后要执行的代码，来处理赋值`a = 2`。*引擎* 运行的代码首先让 *作用域* 去查看在当前的作用域集合中是否有一个称为`a`的变量可以访问。如果有，*引擎* 就使用这个变量。如果没有，*引擎* 就查看 *其他地方*（参加下面的嵌套 *作用域* 一节）。

如果 *引擎* 最终找到一个变量，它就将值`2`赋予它。如果没有，*引擎* 将会举起它的手并喊出一个错误！

总结来说：对于一个变量赋值，发生了两个不同的动作：第一，*编译器* 声明一个变量（如果先前没有在当前作用域中声明过），第二，当执行时，*引擎* 在 *作用域* 中查询这个变量并给它赋值，如果找到的话。

### 编译器术语 ###

为了继续更深入地理解，我们需要一点儿更多的编译器术语。

当 *引擎* 执行 *编译器* 在第二步中为它产生的代码时，它必须查询变量`a`来看它是否已经被声明过了，而且这个查询是咨询 *作用域* 的。但是 *引擎* 实施的查询的类型会影响查询的结果。

在我们这个例子中，*引擎* 将会对变量`a`实施一个“LHS”查询。另一种查询的类型称为“RHS”。

我打赌你能猜出“L”和“R”是什么意思。这两个术语表示“Left-hand Side（左手边）”和“Right-hand Side（右手边）”

什么的……边？**赋值操作的。**

换言之，当一个变量出现在赋值操作的左手边时，会进行LHS查询，当一个变量出现在赋值操作的右手边时，会进行RHS查询。

实际上，我们可以表述得更准确一点儿。对于我们的目的来说，一个RHS是难以察觉的，因为它简单地查询某个变量的值，而LHS查询是试着找到变量容器本身，以便它可以赋值。从这种意义上说，RHS的含义实质上不是 *真正的* “一个赋值的右手边”，更准确地说，它只是意味着“不是左手边”。

在这一番油腔滑调之后，你也可以认为“RHS”意味着“取得他/她的源（值）”，暗示着RHS的意思是“去取……的值”。

让我们挖掘得更深一些。

当我说：

console.log( a );

这个指向`a`的引用是一个RHS引用，因为这里没有东西被赋值给`a`。而是我们在查询`a`并取得它的值，这样这个值可以被传递进`console.log(..)`。

作为对比：

a = 2;

这里指向`a`的引用是一个LHS引用，因为我们实际上不关心当前的值是什么，我们只是想找到这个变量，将它作为`= 2`赋值操作的目标。

**注意：** LHS和RHS意味着“赋值的左/右手边”未必像字面上那样意味着“`=`赋值操作符的左/右边”。赋值有几种其他的发生形式，所以最好在概念上将它考虑为：“赋值的目标（LHS）”和“赋值的源（RHS）”。

考虑这段程序，它既有LHS引用又有RHS引用：

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

调用`foo(..)`的最后一行作为一个函数调用要求一个指向`foo`的RHS引用，意味着，“去查询`foo`的值，并把它交给我”。另外，`(..)`意味着`foo`的值应当被执行，所以它最好实际上是一个函数！

这里有一个微妙但重要的赋值。**你发现了吗？**

你可能错过了这个代码段隐含的`a = 2`。它发生在当值`2`作为参数值传递给`foo(..)`函数时，这时值`2` **被赋值** 给参数`a`。为了（隐含地）给参数`a`赋值，进行了一个LHS查询。

这里还有一个`a`的值的RHS引用，它的结果值被传入`console.log(..)`。`console.log(..)`需要一个引用来执行。它为`console`对象进行一个RHS查询，然后发生一个属性解析来看它是否有一个称为`log`的方法。

最后，我们可以将这一过程概念化为，在将值`2`（通过变量`a`的RHS查询得到的）传入`log(..)`时发生了一次LHS/RHS的交换。在`log(..)`的原生实现内部，我们可以假定它拥有参数，其中的第一个（也许被称为`arg1`）在`2`被赋值给它之前，进行了一次LHS引用查询。

**注意：** 你可能会试图将函数声明`function foo(a) {...`概念化为一个普通的变量声明和赋值，比如`var foo`和`foo = function(a){...`。这样做会诱使你认为函数声明涉及了一次LHS查询。

然而，一个微妙但重要的不同是，在这种情况下 *编译器* 同时处理声明和代码生成期间的值的定义，如此当 *引擎* 执行代码时，没有必要将一个函数值“赋予”`foo`。因此，认为函数声明是一个我们在这里讨论的LHS查询赋值是不太合适的。

### 引擎/作用域对话 ###

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

让我们将上面的（处理这个代码段的）交互想象为一场对话。这场对话将会有点儿像这样进行：

> ***引擎***：嘿 *作用域*，我有一个`foo`的RHS引用。听说过它吗？
> 
> ***作用域***；啊，是的，听说过。*编译器* 刚在一秒钟之前声明了它。它是一个函数。给你。
> 
> ***引擎***：太棒了，谢谢！好的，我要执行`foo`了。
> 
> ***引擎***：嘿，*作用域*，我得到了一个`a`的LHS引用，听说过它吗？
> 
> ***作用域***：啊，是的，听说过。*编译器* 刚才将它声明为`foo`的一个正式参数了。给你。
> 
> ***引擎***：一如既往的给力，*作用域*。再次感谢你。现在，该把`2`赋值给`a`了。
> 
> ***引擎***：嘿，*作用域*，很抱歉又一次打扰你。我需要RHS查询`console`。听说过它吗？
> 
> ***作用域***：没关系，*引擎*，这是我一天到晚的工作。是的，我得到`console`了。它是一个内建对象。给你。
> 
> ***引擎***：完美。查找`log(..)`。好的，很好，它是一个函数。
> 
> ***引擎***：嘿，*作用域*。你能帮我查一下`a`的RHS引用吗？我想我记得它，但只是想再次确认一下。
> 
> ***作用域***：你是对的，*引擎*。同一个家伙，没变。给你。
> 
> ***引擎***：酷。传递`a`的值，也就是`2`，给`log(..)`。
> 
> ...

### 小测验 ###

检查你目前为止的理解。确保你扮演 *引擎*，并与 *作用域* “对话”：

function foo(a) { var b = a; return a + b; } var c = foo( 2 );

1.  找到所有的LHS查询（有3处！）。
2.  找到所有的RHS查询（有4处！）。

**注意：** 小测验答案参见本章的复习部分！

## 嵌套的作用域 ##

我们说过 *作用域* 是通过标识符名称查询变量的一组规则。但是，通常会有多于一个的 *作用域* 需要考虑。

就像一个代码块儿或函数被嵌套在另一个代码块儿或函数中一样，作用域被嵌套在其他的作用域中。所以，如果在直接作用域中找不到一个变量的话，*引擎* 就会咨询下一个外层作用域，如此继续直到找到这个变量或者到达最外层作用域（也就是全局作用域）。

考虑这段代码：

function foo(a) { console.log( a + b ); } var b = 2; foo( 2 ); // 4

`b`的RHS引用不能在函数`foo`的内部被解析，但是可以在包围着它的 *作用域*（这个例子中是全局作用域）中解析。

所以，重返 *引擎* 和 *作用域* 的对话，我们会听到：

> ***引擎***：“嘿，`foo`的 *作用域*，听说过`b`吗？我得到一个它的RHS引用。”
> 
> ***作用域***：“没有，从没听说过。问问别人吧。”
> 
> ***引擎***：“嘿，`foo`外面的 *作用域*，哦，你是全局 *作用域*，好吧，酷。听说过`b`吗？我得到一个它的RHS引用。”
> 
> ***作用域***：“是的，当然有。给你。”

遍历嵌套 *作用域* 的简单规则：*引擎* 从当前执行的 *作用域* 开始，在那里查找变量，如果没有找到，就在上一级继续查找，如此类推。如果到了最外层的全局作用域，那么查找就会停止，无论它是否找到了变量。

### 建筑的隐喻 ###

为了将嵌套 *作用域* 解析的过程可视化，我想让你考虑一下这个高层建筑。

![1240][]

fig1.png

这个建筑物表示我们程序的嵌套 *作用域* 规则集合。无论你在哪里，建筑的第一层表示你当前执行的 *作用域*。建筑的顶层表示全局  *作用域*。

你通过在你当前的楼层中查找来解析LHS和RHS引用，如果你没有找到它，就做电梯到上一层楼，在那里寻找，然后再上一层，如此类推。一旦你到了顶层（全局  *作用域*），你要么找到了你想要的东西，要么没有。但是不管怎样你都不得不停止了。

## 错误 ##

为什么我们区别LHS和RHS那么重要？

因为在变量还没有被声明（在所有被查询的 *作用域* 中都没找到）的情况下，这两种类型的查询的行为不同。

考虑如下代码：

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

当`b`的RHS查询第一次发生时，它是找不到的。它被说成是一个“未声明”的变量，因为它在作用域中找不到。

如果RHS查询在嵌套的 *作用域* 的任何地方都找不到一个值，这会导致 *引擎* 抛出一个`ReferenceError`。必须要注意的是这个错误的类型是`ReferenceError`。

相比之下，如果 *引擎* 在进行一个LHS查询并到达了顶层（全局 *作用域*）都没有找到它，而且如果程序没有运行在“Strict模式”\[1\]下，那么这个全局 *作用域* 将会在 **全局作用域中** 创建一个同名的新变量，并把它交给*引擎*。

*“不，之前没有这样的东西，但是我可以帮忙给你创建一个。”*

在ES5中被加入的“Strict模式”\[1\]，有许多与一般/宽松/懒惰模式不同的行为。其中之一就是不允许自动/隐含的全局变量创建。在这种情况下，将不会有全局 *作用域* 的变量交回给LHS查询，并且类似于RHS的情况, *引擎* 将抛出一个`ReferenceError`。

现在，如果一个RHS查询的变量被找到了，但是你试着去做一些这个值不可能做到的事，比如将一个非函数的值作为函数运行，或者引用`null`或者`undefined`值的属性，那么 *引擎* 就会抛出一个不同种类的错误，称为`TypeError`。

`ReferenceError`是关于 *作用域* 解析失败的，而`TypeError`暗示着  *作用域* 解析成功了，但是试图对这个结果进行了一个非法/不可能的动作。

## 复习 ##

作用域是一组规则，它决定了在哪里和如何查找一个变量（标识符）。这种查询也许是为了向这个变量赋值，这时变量是一个LHS（左手边）引用，或者是为取得它的值，这时变量是一个RHS（右手边）引用。

LHS引用得自赋值操作。*作用域* 相关的赋值可以通过`=`操作符发生，也可以通过向函数参数传递（赋予）参数值发生。

JavaScript *引擎* 在执行代码之前首先会编译它，这样做，它将`var a = 2;`这样的语句分割为两个分离的步骤：

1.  首先，`var a`在当前 *作用域* 中声明。这是在最开始，代码执行之前实施的。
2.  稍后，`a = 2`查找这个变量（LHS引用），并且如果找到就向它赋值。

LHS和RHS引用查询都从当前执行中的 *作用域* 开始，如果有需要（也就是，它们在这里没能找到它们要找的东西），它们会在嵌套的 *作用域* 中一路向上，一次一个作用域（层）地查找这个标识符，直到它们到达全局作用域（顶层）并停止，既可能找到也可能没找到。

未满足的RHS引用会导致`ReferenceError`被抛出。未满足的LHS引用会导致一个自动的，隐含地创建的同名全局变量（如果不是“Strict模式”\[1\]），或者一个`ReferenceError`（如果是“Strict模式”\[1\]）。

### 小测验答案 ###

function foo(a) { var b = a; return a + b; } var c = foo( 2 );

1.  找出所有的LHS查询（有3处！）。
    
    **`c = ..`, `a = 2`（隐含的参数赋值）和`b = ..`**
2.  找出所有的RHS查询（有4处！）。
    
    **`foo(2..`, `= a;`, `a + ..`和`.. + b`**

文／HetfieldJoe（简书作者）  
原文链接：http://www.jianshu.com/p/efe38b392f53\#

[1240]: /images/20220714/932f676cd0e242b0a3ad65d5da7d3db3.png

你不懂JS：作用域与闭包第一章：什么是作用域？

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关 JavaScript-什么是作用域，作用域和作用域链，js没有块级作用域

相关 js 作用域有哪些？闭包是什么？

相关作用域和闭包

相关闭包作用域理解

相关 JavaScript闭包（作用域和作用域链）

相关你不懂JS：作用域与闭包第四章：提升

相关你不懂JS：作用域与闭包第三章：函数与块儿作用域

相关你不懂JS：作用域与闭包第二章：词法作用域

相关你不懂JS：作用域与闭包第一章：什么是作用域？

相关你不懂JS：作用域与闭包第五章：作用域闭包