Appearance

💤 ​

《你不知道的 JavaScript》

作用域是什么？ ​

几乎所有编程语言最基本的功能之一，就是能够存储变量当中的值，并且能在之后对这个值进行访问或修改。事实上，正是这种存储和访问变量的值的能力将状态带给了程序。

若没有了状态这个概念，程序虽然也能执行一些简单的任务，但它们将会受到极大的限制而且不会非常有趣。

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

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

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

编译器理论 ​

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

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

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

  1. 分词/词法分析：将一连串字符打断成（对于语言来说）有意义的片段，称为 token（记号）。举例来说，考虑这段程序：var a = 2;。这段程序很可能会被打断成如下 token：var，a，=，2，;。空格也许会被保留为一个 token，这要看它是否是有意义的。

    NOTE

    分词和词法分析之间的区别是微妙和学术上的，其中心在于这些 token 是否以无状态或有状态的方式被识别。简而言之，如果分词器去调用有状态的解析规则来弄清a是否应当被考虑为一个不同的 token，还是只是其他 token 的一部分，那么这就是词法分析。

  2. 解析： 将一个 token 的流（数组）转换为一个嵌套元素的树，它综合地表示了程序的语法结构。这棵树称为“抽象语法树”（AST —— Abstract Syntax Tree）。

    var a = 2;的树也许开始于称为VariableDeclaration（变量声明）顶层节点，带有一个称为Identifier（标识符）的子节点（它的值为a）, 和另一个称为AssignmentExpression（赋值表达式）的子节点，而这个子节点本身带有一个称为NumericLiteral（数字字面量）的子节点（它的值为2）。

  3. 代码生成：这个处理将抽象语法树转换为可执行的代码。这一部分将根据语言，它的目标平台等因素有很大的不同。

    所以，与其深陷细节，我们不如笼统地说，有一种方法将我们上面描述的var a = 2;的抽象语法树转换为机器指令，来实际上创建一个称为a的变量（包括分配内存等等），然后在a中存入一个值。

    NOTE

    引擎如何管理系统资源的细节远比我们要挖掘的东西深刻，所以我们将理所当然地认为引擎有能力按其需要创建和存储变量。

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

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

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

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

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

理解作用域 ​

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

演员 ​

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

  1. 引擎：负责从始至终的编译和执行我们的 JS 程序。

  2. 编译器：引擎的朋友之一；处理所有的解析和代码生成的重活儿（见前一节）。

  3. 作用域：引擎的另一个朋友；收集并维护一张所有被声明的标识符（变量）的列表，并对当前执行中的代码如何访问这些变量强制实施一组严格的规则。

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

反复 ​

当你看到程序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 的意思是“去取...的值”。

让我们挖掘的更深一些。

当我说：

javascript
console.log(a)

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

作为对比：

javascript
a = 2

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

NOTE

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

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

javascript
function foo(a) {
  console.log(a)
}
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 引用查询。

NOTE

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

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

引擎/作用域对话 ​

javascript
function foo(a) {
  console.log(a)
}
foo(2)

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

引擎：嘿作用域，我有一个foo的 RHS 引用。听说过它吗？

作用域：啊，是的，听说过。编译器刚在一秒钟之前声明了它。它是一个函数。给你。

引擎：太棒了，谢谢！好的，我要执行foo了。

引擎：嘿作用域，我得到了一个a的 LHS 引用。听说过它吗？

作用域：啊，是的，听说过。编译器刚才将它声明为foo的一个正式参数了，给你。

引擎：一如既往的给力，作用域。再次感谢你。现在，该把2赋值给a了。

引擎：嘿，作用域，很抱歉又一次打扰你。我需要 RHS 查询console。听说过它吗？

作用域：没关系，引擎，这是我一天到晚的工作。是的，我得到console了。它是一个内建对象。给你。

引擎：完美。查找log(..)。好的，很好，它是一个函数。

引擎：嘿，作用域，你能帮我查一下a的 RHS 引用吗？我想我记得它，但只是想再次确认一下。

作用域：你是对的，引擎。同一个家伙，没变。给你。

引擎：酷。传递a的值，也就是2，给log(..)。

...

小测验 ​

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

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

  1. 找到所有的 LHS 查询（有 3 处！）

  2. 找到所有的 RHS 查询（有 4 处！）

NOTE

小测验答案参见本章的复习部分！

嵌套的作用域 ​

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

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

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

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

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

引擎：“嘿，foo的作用域，听说过b吗？我得到一个它的 RHS 引用。”

作用域：“没有，从没听说过，问问别人去吧。”

引擎：“嘿，foo外面的作用域，哦，你是全局作用域，好吧，酷。听说过b吗？我得到一个它的 RHS 引用。”

作用域：“是的，当然有。给你。”

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

建筑的隐喻 ​

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

建筑的隐喻

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

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

错误 ​

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

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

考虑如下代码：

javascript
function foo(a) {
  console.log(a + b)
  b = a // 这行代码和上边一行代码颠倒顺序就能正常运行
}
foo(2)

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

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

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

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

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

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

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

复习 ​

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

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

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

  1. 首先，var a在当前作用域中声明。这是在最开始，代码执行之前实施的。

  2. 稍后，a = 2查找这个变量（LHS 引用），并且如果找到就向它赋值。

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

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

小测验答案 ​

javascript
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

  1. MDN: Strict Mode ↩︎ ↩︎ ↩︎ ↩︎