你不懂JS：作用域与闭包
第一章：什么是作用域？
几乎所有语言的最基础模型之一就是在变量中存储值，并且在稍后取出或修改这些值的能力。事实上，在变量中存储值和取出值的能力，给程序赋予了 状态。
如果没有这样的概念，一个程序虽然可以执行一些任务，但是它们将会受到极大的限制而且不会非常有趣。
但是在我们的程序中纳入变量，引出了我们现在将要解决的最有趣的问题：这些变量 存活 在哪里？换句话说，它们被存储在哪儿？而且，最重要的是，我们的程序如何在需要它们的时候找到它们？
回答这些问题需要一组明确定义的规则，它定义如何在某些位置存储变量，以及如何在稍后找到这些变量。我们称这组规则为：作用域。
但是，这些 作用域 规则是在哪里、如何被设置的？
编译器理论
根据你与各种编程语言打交道的水平不同，这也许是不证自明的，或者这也许令人吃惊，尽管 JavaScript 一般被划分到“动态”或者“解释型”语言的范畴，但是其实它是一个编译型语言。它 不是 像许多传统意义上的编译型语言那样预先被编译好，编译的结果也不能在各种不同的分布式系统间移植。
但是无论如何，JavaScript 引擎在实施许多与传统的语言编译器相同的步骤，虽然是以一种我们不易察觉的更精巧的方式。
在传统的编译型语言处理中，一块儿源代码，你的程序，在它被执行 之前 通常将会经历三个步骤，大致被称为“编译”：
-
分词/词法分析： 将一连串字符打断成（对于语言来说）有意义的片段，称为 token（记号）。举例来说，考虑这段程序：
var a = 2;。这段程序很可能会被打断成如下 token：var，a，=，2，和;。空格也许会被保留为一个 token，这要看它是否是有意义的。注意： 分词和词法分析之间的区别是微妙和学术上的，其中心在于这些 token 是否以 无状态 或 有状态 的方式被识别。简而言之，如果分词器去调用有状态的解析规则来弄清
a是否应当被考虑为一个不同的 token，还是只是其他 token 的一部分，那么这就是 词法分析。 -
解析： 将一个 token 的流（数组）转换为一个嵌套元素的树，它综合地表示了程序的语法结构。这棵树称为“抽象语法树”（AST —— Abstract Syntax Tree）。
var a = 2;的树也许开始于称为VariableDeclaration（变量声明）顶层节点，带有一个称为Identifier（标识符）的子节点（它的值为a），和另一个称为AssignmentExpression（赋值表达式）的子节点，而这个子节点本身带有一个称为NumericLiteral（数字字面量）的子节点（它的值为2）。 -
代码生成： 这个处理将抽象语法树转换为可执行的代码。这一部分将根据语言，它的目标平台等因素有很大的不同。
所以，与其深陷细节，我们不如笼统地说，有一种方法将我们上面描述的
var a = 2;的抽象语法树转换为机器指令，来实际上 创建 一个称为a的变量（包括分配内存等等），然后在a中存入一个值。注意： 引擎如何管理系统资源的细节远比我们要挖掘的东西深刻，所以我们将理所当然地认为引擎有能力按其需要创建和存储变量。
和大多数其他语言的编译器一样，JavaScript 引擎要比这区区三步复杂太多了。例如，在解析和代码生成的处理中，一定会存在优化执行效率的步骤，包括压缩冗余元素，等等。
所以，我在此描绘的只是大框架。但是我想你很快就会明白为什么我们涵盖的这些细节是重要的，虽然是在很高的层次上。
其一，JavaScript 引擎没有（像其他语言的编译器那样）大把的时间去优化，因为 JavaScript 的编译和其他语言不同，不是提前发生在一个构建的步骤中。
对 JavaScript 来说，在许多情况下，编译发生在代码被执行前的仅仅几微秒之内（或更少！）。为了确保最快的性能，JS 引擎将使用所有的招数（比如 JIT，它可以懒编译甚至是热编译，等等），而这远超出了我们关于“作用域”的讨论。
为了简单起见，我们可以说，任何 JavaScript 代码段在它执行之前（通常是 刚好 在它执行之前！）都必须被编译。所以，JS 编译器将把程序 var a = 2; 拿过来，并首先编译它，然后准备运行它，通常是立即的。
理解作用域
我们将采用的学习作用域的方法，是将这个处理过程想象为一场对话。但是，谁 在进行这场对话呢？
演员
让我们见一见处理程序 var a = 2; 时进行互动的演员吧，这样我们就能理解稍后将要听到的它们的对话：
引擎：负责从始至终的编译和执行我们的 JavaScript 程序。
编译器：引擎 的朋友之一；处理所有的解析和代码生成的重活儿（见前一节）。
作用域：引擎 的另一个朋友；收集并维护一张所有被声明的标识符（变量）的列表，并对当前执行中的代码如何访问这些变量强制实施一组严格的规则。
为了 全面理解 JavaScript 是如何工作的，你需要开始像 引擎（和它的朋友们）那样 思考，问它们问的问题，并像它们一样回答。
反复
当你看到程序 var a = 2; 时，你很可能认为它是一个语句。但这不是我们的新朋友 引擎 所看到的。事实上，引擎 看到两个不同的语句，一个是 编译器 将在编译期间处理的，一个是 引擎 将在执行期间处理的。
那么，让我们来分析 引擎 和它的朋友们将如何处理程序 var a = 2;。
编译器 将对这个程序做的第一件事情，是进行词法分析来将它分解为一系列 token，然后这些 token 被解析为一棵树。但是当 编译器 到了代码生成阶段时，它会以一种与我们可能想象的不同的方式来对待这段程序。
一个合理的假设是，编译器 将产生的代码可以用这种假想代码概括：“为一个变量分配内存，将它标记为 a，然后将值 2 贴在这个变量里”。不幸的是，这不是十分准确。
编译器 将会这样处理：
遇到
var a，编译器 让 作用域 去查看对于这个特定的作用域集合，变量a是否已经存在了。如果是，编译器 就忽略这个声明并继续前进。否则，编译器 就让 作用域 去为这个作用域集合声明一个称为a的新变量。然后 编译器 为 引擎 生成稍后要执行的代码，来处理赋值
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 );
找到所有的 LHS 查询（有3处！）。
找到所有的 RHS 查询（有4处！）。
注意： 小测验答案参见本章的复习部分！
嵌套的作用域
我们说过 作用域 是通过标识符名称查询变量的一组规则。但是，通常会有多于一个的 作用域 需要考虑。
就像一个代码块儿或函数被嵌套在另一个代码块儿或函数中一样，作用域被嵌套在其他的作用域中。所以，如果在直接作用域中找不到一个变量的话，引擎 就会咨询下一个外层作用域，如此继续直到找到这个变量或者到达最外层作用域（也就是全局作用域）。
考虑这段代码：
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 那么重要？
因为在变量还没有被声明（在所有被查询的 作用域 中都没找到）的情况下，这两种类型的查询的行为不同。
考虑如下代码：
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; 这样的语句分割为两个分离的步骤：
首先，
var a在当前 作用域 中声明。这是在最开始，代码执行之前实施的。稍后，
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 );
-
找出所有的 LHS 查询（有3处！）。
c = ..,a = 2（隐含的参数赋值）和b = .. -
找出所有的 RHS 查询（有4处！）。
foo(2..,= a;,a + ..和.. + b
-
MDN: Strict Mode ↩ ↩ ↩ ↩