作用域共有两种主要的工作模型。第一种是最为普遍的，被大多数编程语言所采用的词法 作用域，我们会对这种作用域进行深入讨论。另外一种叫作动态作用域，仍有一些编程语 言在使用(比如 Bash 脚本、Perl 中的一些模式等)。
简单地说，词法作用域就是定义在词法阶段的作用域。换句话说，词法作用域是由你在写 代码时将变量和块作用域写在哪里来决定的，因此当词法分析器处理代码时会保持作用域 不变(大部分情况下是这样的)。
考虑以下代码：
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
作用域气泡由其对应的作用域块代码写在哪里决定，他们是逐级包含的。这里假设每一个函数都会创建一个新的作用域就好了。
bar 的气泡被完全包含在foo所创建的气泡中，唯一的原因是哪里就是我们希望定义函数bar的位置。
这里的所有的包含是严格包含的。换句话说，没有任何函数的气泡可以同时出现在两个外部作用域的气泡中，就如同没有任何函数可以部分地同时出现在两个父级函数中一样。
查找
作用域气泡的结构和互相之间的位置关系给引擎提供了足够的位置信息，引擎用这些信息来查找标识符的位置。
在上一个代码片段中，引擎执行console.log(...)声明，并查找a、b和三个变量的引用，它首先从最内部的作用域，也就是bar(...)函数的作用域气泡开始查找。引擎无法在这里找到a,因此会去上一级到做嵌套的foo(...)的作用域中继续查找。在这里找到了a,因此引擎使用了这个引用。对于b也是一样的。而对c来说，引擎在bar(...)中就找到了它。
作用域查找会在找到第一个匹配的标识符就停止。在多层的嵌套作用域中可以定义同名的标识符，这叫做“遮蔽效应”（内部的标识符遮蔽了外部的标识符）抛开遮蔽效应，作用域查找始终从运行时所处的最内部作用域开始，逐级向外或者说向上进行，直到遇见第一个匹配的标识符为止。
全局变量会自动成为全局对象的属性，因此可以不直接通过全局对象的词法名称，而是间接地通过对全局对象属性的引用来对其进行访问。
通过这种技术可以访问那些被同名变量所遮蔽的全局变量。但是非全局的变量如果被遮蔽了，无论如何都是无法被访问到。
无论函数在哪里被调用。也无论如何被调用，他的词法作用域都只是由函数被声明时所处的位置决定。
词法作用域只会查找一级标识符，比如a、b、c、如果代码中引用了 foo.bar.baz词法作用域查找只会试图查找foo标识符，找到这个变量之后，对象属性访问规则会分别接管对bar和baz属性的访问。
欺骗词法
如果词法作用域完全由写代码期间函数所声明的位置来决定，怎样才能在运行时来"修改"（也可以说欺骗）词法作用域呢？
js中有两种机制来实现这个目的，社区普遍认为在代码中使用这两种机制并不是什么好主意，但是关于他们的争论通常会忽略掉最重要的点：欺骗词法作用域会导致性能下降。
eval
js中的eval(...)函数可以接收一个字符串为参数，并将其中的内容视为好像在书写的时候就存在程序中这个位置的代码。换句话说，可以在你写代码的中用程序生成代码并运行，就好像代码是写在那个位置一样。
根据这个原理来理解 eval(...) 它是如何通过代码欺骗和假装成书写时(也就是词法期)代码就在那里，来实现修改词法作用域环境的，这个原理就变的清晰易懂了。
在执行eval(...)之后的代码时，引擎并不”知道“或者”在意“前面的代码时以动态形式插入进来，并对词法作用域的环境进行修改，引擎只会如往常一样进行词法作用域查找。
考虑以下代码：
function foo(str,a){
eval(str); // 欺骗！
console.log(a,b);
}
var b = 2;
foo("var b = 3",1); // 1,3
eval(...) 调用中的 "var b = 3;"这段代码会被当做本来就在那里一样来处理。由于那段代码声明了一个新的变量b,因此它对已经存在的foo(...)的词法作用域进行了修改。事实上，和前面所说的原理一样，这段代码实际上在foo(...)内部创建了变量b,并这逼了外部(全局)作用域中的同名变量。
当console.log(...)被执行的时候，会在foo(...)的内部同事找到a和b 但是永远也无法找到外部的b,因此会输出”1，3“而不是正常情况下会输出”1，2“.
在这个例子中，为了展示的方便和简洁，我们传递进去的”代码“字符串是固定不变的。而在实际开发中，可以非常容易地根据程序逻辑动态地将字符拼接在一起之后再传递进去。eval(...)通常被用来执行动态创建的代码，因为像例子中这样动态地执行一段固定字符所组成的代码，并没有比直接将代码卸载哪里更有好处。
with
Javascript 中的另一个难以掌握（并且现在也不推荐使用）的用来欺骗词法作用域的功能是with关键字。可以有很多的方法来解释with，在这里我选择一个角度来解释它；它如何同被它所影响的词法作用域进行交互。
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);
foo(o2);
console.log(o2.a);
console.log(a);
在这个例子中创建了o1和o2两个对象。其中一个具有a属性，另外一个没有。foo(...)
函数接受obj参数，让参数是一个对象引用，并对这个对象引用执行了with(obj){...}
在with块内部，我们写的代码看起来知识对变量a进行简单的词法引用，实际上就是一个LHS引用，并将2赋值给它。
当我们将 o1 传递进去，a=2 赋值操作找到了 o1.a 并将 2 赋值给它，这在后面的 console. log(o1.a) 中可以体现。而当 o2 传递进去，o2 并没有 a 属性，因此不会创建这个属性， o2.a 保持 undefined。
但是可以注意到一个奇怪的副作用，实际上 a = 2 赋值操作创建了一个全局的变量 a。这 是怎么回事?
with 可以将一个没有或有多个属性的对象处理为一个完全隔离的词法作用域，因此这个对 象的属性也会被处理为定义在这个作用域中的词法标识符。
性能
eval(..) 和 with 会在运行时修改或创建新的作用域，以此来欺骗其他在书写时定义的词法作用域。
你可能会问，那又怎样呢? 如果它们能实现更复杂的功能，并且代码更具有扩展性，难道
不是非常好的功能吗?答案是否定的。
JavaScript 引擎会在编译阶段进行数项的性能优化。其中有些优化依赖于能够根据代码的 词法进行静态分析，并预先确定所有变量和函数的定义位置，才能在执行过程中快速找到 标识符。
但如果引擎在代码中发现了 eval(..) 或 with，它只能简单地假设关于标识符位置的判断 都是无效的，因为无法在词法分析阶段明确知道 eval(..) 会接收到什么代码，这些代码会 如何对作用域进行修改，也无法知道传递给 with 用来创建新词法作用域的对象的内容到底 是什么。
最悲观的情况是如果出现了 eval(..) 或 with，所有的优化可能都是无意义的，因此最简 单的做法就是完全不做任何优化。
如果代码中大量使用 eval(..) 或 with，那么运行起来一定会变得非常慢。无论引擎多聪 明，试图将这些悲观情况的副作用限制在最小范围内，也无法避免如果没有这些优化，代 码会运行得更慢这个事实。
总结
词法作用域意味着作用域是由书写代码时函数声明的位置来决定的。编译的词法分析阶段 基本能够知道全部标识符在哪里以及是如何声明的，从而能够预测在执行过程中如何对它 们进行查找。
JavaScript 中有两个机制可以“欺骗”词法作用域:eval(..) 和 with。前者可以对一段包 含一个或多个声明的“代码”字符串进行演算，并借此来修改已经存在的词法作用域(在 运行时)。后者本质上是通过将一个对象的引用当作作用域来处理，将对象的属性当作作 用域中的标识符来处理，从而创建了一个新的词法作用域(同样是在运行时)。
这两个机制的副作用是引擎无法在编译时对作用域查找进行优化，因为引擎只能谨慎地认 为这样的优化是无效的。使用这其中任何一个机制都将导致代码运行变慢。不要使用它们。
参考《你不知道的JavaScript》上卷
