JS黄书笔记（一）作用域在传统的编译语言中，程序中的一段源代码在执行之前会经历三个步骤，统称为“编译”。语法分析：这个

一、作用域扫盲

编译原理

在传统的编译语言中，程序中的一段源代码在执行之前会经历三个步骤，统称为“编译”。

词法分析：把由字符组成的字符串分解成有意义的代码块，这些代码块被称为词法单元 （var , a , = , 2 , ;）
语法分析：这个过程是将词法单元流（数组）转换成一个由元素逐级嵌套所组成的代表了程序语法结构的树。这个树被称为抽象语法树（Abstract Syntax Tree，AST）
代码生成：将AST转换为可执行代码的过程被称为代码生成。这个过程与语言、目标平台等息息相关。抛开具体细节，简单来说就是有某种方法可以将var a = 2; 的AST转化为一组机器指令，用来创建一个叫作 a 的变量（包括分配内存等），并将一个值储存在 a 中。

JavaScript 引擎不会有大量的时间用来进行优化，因为与其他语言不同，JavaScript 的编译过程不是发生在构建之前的。 JavaScript 代码片段在执行前都要进行编译。比如，JavaScript 编译器首先会对 var a = 2; 这段程序进行编译，然后做好执行它的准备，然后马上执行它。

理解作用域

引擎从头到尾负责整个 JavaScript 程序的编译及执行过程。
编译器负责语法分析及代码生成。
作用域负责收集并维护由所有声明的标识符（变量）组成的一系列查询，并实施一套非常严格的规则，确定当前执行的代码对这些标识符的访问权限。

变量的赋值操作会执行两个动作，首先编译器会在当前作用域中声明一个变量（如果之前没有声明过），然后在运行时引擎会在作用域中查找该变量，如果能够找到就会对它赋值。

个人理解，引擎的编译器负责提升，之后引擎再负责执行

LHS 和 RHS

引擎的读值操作就是RHS
引擎的赋值操作就是LHS

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

让我们把上面这段代码的处理过程想象成一段对话，这段对话可能是下面这样的。

引擎：我说作用域，我需要为 foo 进行 RHS 引用。你见过它吗？
作用域：别说，我还真见过，编译器那小子刚刚声明了它。它是一个函数，给你。
引擎：哥们太够意思了！好吧，我来执行一下 foo。
引擎：作用域，还有个事儿。我需要为 a 进行 LHS 引用，这个你见过吗？
作用域：这个也见过，编译器最近把它声名为 foo 的一个形式参数了，拿去吧。
引擎：大恩不言谢，你总是这么棒。现在我要把 2 赋值给 a。
引擎：哥们，不好意思又来打扰你。我要为 console 进行 RHS 引用，你见过它吗？
作用域：咱俩谁跟谁啊，再说我就是干这个。这个我也有，console 是个内置对象。给你。
引擎：么么哒。我得看看这里面是不是有 log(..)。太好了，找到了，是一个函数。
引擎：哥们，能帮我再找一下对 a 的 RHS 引用吗？虽然我记得它，但想再确认一次。
作用域：放心吧，这个变量没有变动过，拿走，不谢。
引擎：真棒。我来把 a 的值，也就是 2，传递进 log(..)。
……

如果 RHS 查询在所有嵌套的作用域中遍寻不到所需的变量，引擎就会抛出 ReferenceError 异常。值得注意的是，ReferenceError 是非常重要的异常类型。

相较之下，当引擎执行 LHS 查询时，如果在顶层（全局作用域）中也无法找到目标变量，全局作用域中就会创建一个具有该名称的变量，并将其返还给引擎，前提是程序运行在非 “严格模式”下。

二、词法作用域

词法作用域是由你在写代码时将变量和块作用域 写在哪里来决定的，因此当词法分析器处理代码时会保持作用域不变（大部分情况下是这样的）。

function foo(a) { 
var b = a * 2; 
function bar(c) { 
 console.log( a, b, c ); 
 } 
 bar( b * 3 ); 
} 
foo( 2 ); // 2, 4, 12

1 包含着整个全局作用域，其中只有一个标识符：foo。
2 包含着 foo 所创建的作用域，其中有三个标识符：a、bar 和 b。
3 包含着 bar 所创建的作用域，其中只有一个标识符：c。

作用域气泡由其对应的作用域块代码写在哪里决定，它们是逐级包含的。

查找

作用域查找会在找到第一个匹配的标识符时停止。

无论函数在哪里被调用，也无论它如何被调用，它的词法作用域都只由函数被声明时所处的位置决定。

在多层的嵌套作用域中可以定义同名的标识符，这叫作“遮蔽效应”

欺骗词法

非严格模式下的evel()函数

function foo(str, a) { 
 eval( str ); // 欺骗！
 console.log( a, b ); 
} 
var b = 2; 
foo( "var b = 3;", 1 ); // 1, 3

非严格模式下的 with 关键字

var obj = {
        a: 1,
        b: 2,
        c: 3
    };
    // 单调乏味的重复 "obj" 
    obj.a = 2;
    obj.b = 3;
    obj.c = 4;
    // 简单的快捷方式
    with (obj) {
        a = 3;
        b = 4;
        c = 5;
    }

然而

    function foo(obj) {
        with (obj) {
            a = 2;
        }
    }

    var o1 = {
        a: 3
    };
    var o2 = {
        b: 3
    };
    foo(o1);
    console.log(o1.a); // 2 
    foo(o2);
    console.log(o2.a); // undefined 
    console.log(a); // 2——不好，a 被泄漏到全局作用域上了！

如果引擎在代码中发现了eval(..) 或 with，它只能简单地假设关于标识符位置的判断都是无效的，因为无法在词法分析阶段明确知道 eval(..) 会接收到什么代码，这些代码会如何对作用域进行修改，也无法知道传递给 with 用来创建新词法作用域的对象的内容到底是什么。最悲观的情况是如果出现了 eval(..) 或 with，所有的优化可能都是无意义的，因此最简单的做法就是完全不做任何优化。