几乎所有的编程语言最基本的功能之一，就是能够储存变量中的值，并且能在之后对这个值进行访问或修改。事实上，正是这种储存和访问变量的值的能力将状态带给了程序。
若没有了状态这个概念，程序虽然也能够执行一些简单的任务，但它会受到高度限制，做不到非常有趣。
但是将变量引入程序会引起几个很有意思的问题，也正是我们将要讨论的：这些变量住在哪里？换句话说，它们储存在哪里？最重要的是，程序需要时如何找到它们？
这些问题说明需要一套设计良好的规则来存储变量，并且之后可以方便的找到这些变量，这套规则被称为作用域。
但是，究竟在哪里而且怎样设置这些作用域的规则呢？
编译原理•分词、词法分析•解析、语法分析•代码生成
笔记：分词、词法分析，是将代码拆解为块
解析、语法分析，会将块转换成抽象语法树
尽管通常将 JavaScript 归类为「动态」或「解释执行」语言，但事实上它是一门编译语言。这个事实对你来说可能显而易见，也可能你闻所未闻，取决于你接触过多少编程语言，具有多少经验。但与传统的编译语言不同，它不是提前编译的，编译结果也不能在分布式系统中进行移植。
尽管如此，JavaScript 引擎进行编译的步骤和传统的编译语言非常相似，在某些环节可能比预想的的要复杂。
在传统编译语言的流程中，程序中的一段源代码在执行之前会经历三个步骤，统称为「编译」。
•分词/词法分析
这个过程会将字符组成的字符串的分解成有意义的代码块，这些代码被称为词法单元。
例如程序 var a = 2；这段程序通常会被分解成为下面这些词法单元：var、a、=、2、；。空格是否会被当作词法单元，取决于空格在这门语言中是否有意义。
分词和词发分析之间的区别是非常微妙、晦涩的，主要差异在于词法单元的识别是通过有状态还是无状态的方式进行的。简单来说，如果词法单元生成器在判断 a 是一个独立的词法单元，还是其他词法单元的一部分时，调用的是有状态的解析规则，那个这个过程就被称为词发分析。
•解析、语法分析
这个过程是词法单元流转换成一个由元素逐渐嵌套所组成的代表了程序语法结构的树。这个树被称为「抽象语法树」。
var a = 2；的抽象语法树可能会是一个叫做 variableDeclaration 顶级节点，接下来是一个叫做 Identifer 的子节点，以及一个叫做 AssignmentExpression 的子节点。AssignmentExpression 节点有一个叫作 NumericLiteral 的子节点。
•代码生成
将 AST 转换为可执行代码的过程被称被代码生成。这个过程与语言、目标平台等息息相关。
抛开具体细节，简单来说就是有某种方法可以将 var a = 2；的 AST 转化为一组机器指令，用来创建一个叫做 a 的变量，并将一个值存储在 a 中。
比起哪些编译过程只有三个步骤的语言的编译器，JavaScript 引擎要复杂的多。例如，比语法分析和代码生成阶段有特定的步骤来运行性能进行优化，包括对冗余元素进行优化等。
因此在这里只进行宏观、简单的介绍，接下来你就会发现我们介绍的这些——看起来高深的内容，与所要讨论的内容有什么关联。
首先，JavaScript 引擎不会有大量的时间来进行优化，因为 JavaScript 的编译过程不是发生在构建之前的。
对于 JavaScript 来说，大部分编译情况发生在代码执行前的几微秒的时间内。在我们所要讨论的作用域背后，JavaScript 引擎用尽了各种办法（JIT、延迟编译、重编译）来保证性能最佳。
任何 JavaScript 代码片段在执行前都要进行编译，因此，JavaScript 编译器首先会对 var a = 2 ；这段代码进行编译，然后做好执行它的准备，并且通常会立即执行它。
理解作用域•引擎：从头到尾负责整个 JavaScript 程序的编译以及执行过程。（全栈程序员，只用埋头干活）•编译器：引擎的好朋友，负责语法分析及代码生成等脏活累活。（项目经理，分析项目结构，将项目拆分成开发任务）•作用域：引擎的另一位好朋友，负责收集并维护所有声明的标识符——也就是变量，所组成的一系列查询，并实施一套非常严格的规则，确定当前执行的代码对这些标识符的访问权限。（产品经理：界定项目边界）
为了能够完全理解 JavaScript 的工作原理，你需要开始像它们三个一样思考问题，从它们的角度提出问题，并从它们的角度回答问题。
当你看见 var a = 2; 这段程序的时候，很可能认为这是一句声明。但引擎却不这么认为，事实上，引擎认为这里有两个完全不同的声明:
•一个由编译器在编译时处理•另一个则由引擎在运动时引擎在运行时处理。
下面我们将 var a = 2; 分解，看看引擎和它们的朋友是如何协同工作的。
编译器首先会将这段程序分解为词法单元，然后将词法单元解析成一个数结构。但是当编译器开始进行代码生成的时候，它对这段程序的处理方式会和预期有些不同。
可以合理地假设编译器所产生的代码能够用下面的伪代码进行概括：「为一个变量分配内存，将其命名为 a，然后将值 2 保存进这个变量。」然而，这并不完全正确。
事实上，编译器会进行如下处理。
1.遇到 var a，编译器会询问作用域是否已经有一个该名称的变量，存在于同一个作用域的集合中。如果是，编译器会忽略该声明，继续进行编译；否则，它会要求作用域在当前作用域的集合中声明一个新的变量，并命名为 a。2.接下来编译器会为引擎生成运行时所需要的代码，这些代码被用来处理 a = 2 这个赋值操作。引擎运行时会首先询问作用域，在当前的作用域集合中是否存在一个叫做 a 的变量。如果是，引擎就会使用这个变量，如果否，引擎就会继续查找该变量。如果引擎最终找到了 a 变量，就会将 2 赋值给它，否则引擎就会举手示意并抛出一个异常。
变量的赋值会执行两个操作，首先编译器会在当前作用域中声明一个变量，然后在运行时引擎会在作用域中查找该变量，如果找到就会对它进行赋值。
笔记：变量是编译器声明的，赋值语句的右半句的执行代码，最终会由引擎来执行。
编译器有话说编译器在编译的第二步生成了代码，引擎执行它时，会通过查找变量 a 来判断它是否已声明过。查找的过程由作用域进行协助，但是引擎执行怎样的查找，会影响最终的查找结果。
在这里，引擎会为变量 a 进行 LHS 查找，另外一个查找的类型叫做 RHS。
这里的 L 和 R 是左侧和右侧的意思。
什么东西的左侧和右侧？是一个赋值操作的左侧和右侧。
换句话说，当变量出现在赋值操作的左侧时，进行 LHS 查询，出现在 右侧 时进行 RHS 查询。
2//LHS查询 varb=a//RHS查询讲得更准确一点，RHS 查询与简单查找某个变量的值没什么不一样，而 LHS 查询则是试图找到变量的容器本身，从而可以对其赋值。
RHS 查询找的是内存里的值
LHS 查询找的是内存的地址
让我们考虑以下代码：
console.log(a)其中对 a 的引用是一个 RHS 引用，因为这里 a 并没有赋予任何值。相应的，需要查找并去取得 a 的值，这样才能将值传递给 console.log 方法。
相比之下，例如:
a=2;这里对 a 的引用规则是 LHS 引用，因为实际上我们不关心当前的值是什么，只是要为 = 2 这个赋值操作找到一个目标。
LHS 和 RHS 的含义是「赋值操作的左侧或右侧」，并不一定意味着就是等号赋值操作的左侧和右侧。赋值操作还有其他几种形式，因此在概念上最好将其理解为「赋值操作的目标是谁（LHS）」以及「谁是赋值操作的源头（RHS）」
笔记：这里所谓的目标是谁和源头是谁，有点啰里啰嗦的，只需要记住所谓源头，就是找内存地址；所谓目标，就是找内存里的值。
考虑下面的程序，其中既有 RHS 查询，也有 LHS 查询：
functionfoo(a){ console.log(a) } foo(2)最后一行 foo 函数的调用需要对 foo 进行 RHS 引用，意味着「去找到 foo 的值，并把它给我。」并且 （） 意味着需要被执行，因此它最好真的是一个函数类型的值。
这里还有一个容易忽视的细节。
代码中隐式的 a = 2 操作可能很容易被你忽略掉。这个操作发生在 2 作为参数传递给 foo 函数时，2 被分配给参数 a，为了给参数 a 分配值，需要一次 LHS 查询。
这里 还有对 a 进行的 RHS 查询，并且将得到的值传给了 console.log。 console.log 本身也需要一个查询才能执行，因此会对 console 对象进行 RHS 查询，并且检查得到的值是否有一个 log 的方法。
最后，在概念上可以理解为 LHS 和 RHS 之间通过对值 2 进行交互来将其传递给 log 。假设在 log 函数的原生实现中它可以接受参数，在将 2 赋值给其中一个参数之前，这个参数需要进行 LHS 查询。
作用域嵌套
functionfoo(a){ varb=a returna b } varc=foo(2) //LHSfoo(2)a=2一次查找隐式参数a的内存地址 //varb=2,LHS一次，查找的是b的内存地址 //c=foo(2)查找c的内存地址 //RHSfoo(2),查找foo内存地址里的值 //RHSb=a查找a内存地址的值 //RHSb a查找a的值以及b的值作用域是根据名称查找变量的唯一法则，实际情况中，通常需要同时顾忌几个作用域。
当一个块或函数在另一个块或者函数中时，就发生了作用域的嵌套。因此，在当前作用域中无法查找某个变量时，引擎就会在外层嵌套的作用域中继续查找，直到找到该变量，或抵达最外层的作用域（也就是全局作用域）为止。
考虑以下代码：
functionfoo(a){ console.log(a b); } varb=2; foo(2)//4对 b 进行的 RHS 引用无法在函数 foo 内部完成，但可以在上一层作用域中完成。
遍历嵌套作用域的规则很简单：引擎从当前的作用域开始查找，如果找不到，那就向上一级查找，当抵达最外层的全局作用域时，无论如何还是没找到的话，查找过程就会停止。
异常为什么区分 RHS 和 LHS 是一件重要的事？
因为在变量还没有声明的情况下，这两种查询的行为是不一样的。
functionfoo(a){ console.log(a b) b=a } foo(2)第一次对 b 进行 RHS 查询时是无法找到该变量的，也就是说，这是一个未声明的变量，因为在任何相关的作用域中都无法找到它。
如果 RHS 查询在所有嵌套的作用域中都查找不到所需的变量，引擎就会抛出 ReferenceError 异常。值得注意的是，ReferenceError 是非常重要的异常类型。
相较之下，当引擎执行 LHS 查询的时候，如果在顶层（全局作用域）中也无法查找到目标变量，全局作用域就会创建一个具有该名称的变量，并将其返回给引擎，前提是程序运行在非严格模式下。
严格模式禁止自动创建全局变量，引擎查找失败话，会抛出类似的 ReferenceError 异常。
如果 RHS 查询到了一个变量，但是你尝试对这个变量进行不合理的操作，比如试图对一个非函数类型的值进行函数调用时，或者引用 null 或者 undefined 类型的值中的属性，那么引擎就会抛出另一种类型的异常，叫做 TypeError。
ReferenceError 同作用域的判别失败有关，而 TypeError 则表示作用域判别成功了，但是对结果的操作是非法的。
笔记： ReferenceError 是没有找到变量。
TypeError 操作非法，一般和 null 或 undefined 中的属性有关。
小结作用域是一套规则，用于确定何处以及如何查找变量。
如果查找的目的是对变量进行赋值，那么就会使用 LHS 查询。
如果目的是获取变量值，就会使用 RHS 查询。
赋值操作符会导致 LHS 查询， = 操作符或调用函数时传入参数的操作都会导致作用域的赋值操作。
JavaScript 引擎首先会在代码执行前对其进行编译，在这个过程中，像 var a = 2 这样的声明会被分解成两个独立的步骤：
•首先，var a 在其作用域内声明新变量，这会在最开始的阶段，也就是代码执行前执行。•接下来， a = 2 会查询变量 a 并对其进行赋值。（LHS）
LHS 和 RHS 查询都会在当前执行作用域中开始，如果没找到，就会向上一层作用域继续查找，这样每次上升一级作用域，最后抵达全局作用域，如果和没有找到就会停止。
不成功的 RHS 引用会导致抛出 ReferenceError 异常。不成功的 LHS 查询会导致自动隐式地创建一个全局变量（非严格模式下），该变量使用 LHS 引用的目标作为标式符，或者抛出 ReferenceError 异常（严格模式下）
,
