1、词法作用域

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

考虑以下代码：

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。

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

2、欺骗词法

如果词法作用域完全由写代码期间函数所声明的位置来定义，怎样才能在运行时来“修改”（也可以说欺骗）词法作用域呢？
JavaScript 中有两种机制来实现这个目的。社区普遍认为在代码中使用这两种机制并不是什么好注意。但是关于它们的争论通常会忽略掉最重要的点：欺骗词法作用域会导致性能下降。

2.1 eval
JavaScript 中的 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(…) 在运行时有其自己的词法作用域，意味着其中的声明无法修改所在的作用域。

function foo(str) {
	"use strict";
	eval( str );
	console.log( a ); // ReferenceError: a is not defined
}
foo( "var a = 2" );

JavaScript 中 还 有 其 他 一 些 功 能 效 果 和 eval(…) 很 相 似。setTimeout(…) 和setInterval(…) 的第一个参数可以是字符串，字符串的内容可以被解释为一段动态生成的函数代码。这些功能已经过时且并不被提倡。不要使用它们！

new Function(…) 函数的行为也很类似，最后一个参数可以接受代码字符串，并将其转化为动态生成的函数（前面的参数是这个新生成的函数的形参）。这种构建函数的语法比eval(…) 略微安全一些，但也要尽量避免使用。

在程序中动态生成代码的使用场景非常罕见，因为它所带来的好处无法抵消性能上的损失。

2.2 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 ); // 2
foo( o2 );
console.log( o2.a ); // undefined
console.log( a ); // 2——不好，a 被泄漏到全局作用域上了！

eval(…) 函数如果接受了含有一个或多个声明的代码，就会修改其所处的词法作用域，而with 声明实际上是根据你传递给它的对象凭空创建了一个全新的词法作用域。

尽管 with 块可以将一个对象处理为词法作用域，但是这个块内部正常的 var声明并不会被限制在这个块的作用域中，而是被添加到 with 所处的函数作用域中。

2.3 性能
eval(…) 和 with 会在运行时修改或创建新的作用域，以此来欺骗其他在书写时定义的词法作用域。
你可能会问，那又怎样呢？如果它们能实现更复杂的功能，并且代码更具有扩展性，难道不是非常好的功能吗？答案是否定的。

JavaScript 引擎会在编译阶段进行数项的性能优化。其中有些优化依赖于能够根据代码的词法进行静态分析，并预先确定所有变量和函数的定义位置，才能在执行过程中快速找到标识符。
但如果引擎在代码中发现了 eval(…) 或 with，它只能简单地假设关于标识符位置的判断都是无效的，因为无法在词法分析阶段明确知道 eval(…) 会接收到什么代码，这些代码会如何对作用域进行修改，也无法知道传递给 with 用来创建新词法作用域的对象的内容到底是什么。

最悲观的情况是如果出现了 eval(…) 或 with，所有的优化可能都是无意义的，因此最简单的做法就是完全不做任何优化。

如果代码中大量使用 eval(…) 或 with，那么运行起来一定会变得非常慢。无论引擎多聪明，试图将这些悲观情况的副作用限制在最小范围内，也无法避免如果没有这些优化，代码会运行得更慢这个事实。