eval 和 with 详解

欺骗词法

如果词法作用域完全由写代码期间函数所声明的位置来定义，怎样才能在运行时来 ”修改“（也可以说是欺骗）词法作用域呢？

JavaScript 中有两种机制来实现这个目的。社区普遍认为在代码中使用这两种机制并不是好主意。但是关于它们的争论通常会忽略掉最重要的点：欺骗词法作用域会导致性能下降。

eval

JavaScript 中的 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(..) 通常被用来执行动态创建的代码，因为像例子中这样动态的执行一段固定字符串所组成的代码，并没有比直接将代码写在那里更有好处。

默认情况下，如果 eval(..) 中所执行的代码包含有一个或者多个声明（无论是变量还是函数），就会对 eval(..) 所处的词法作用域进行修改。技术上，通过一些技巧可以间接调用 eval(..) 来使其运行在全局作用域中，并对全局作用域进行修改。但无论何种情况，eval(..) 都可以在运行期间修改书写期的词法作用域。

在严格模式的程序中，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(..) 略微安全一些，但也要尽量避免使用。

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

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;
}

//obj 3,4,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 被泄露到全局作用域上了

这个例子中创建了 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 可以将一个没有或有多个属性的对象处理为一个完全隔离的词法作用域，因此这个对象的属性也会被处理为定义在这个作用域中的词法标识符。

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

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

可以这样理解，当我们传递 o1 给 with 时，with 所声明的作用域是 o1，而这个作用域中含有一个同 o1.a 属性相符的标识符。但当我们将 o2 作为作用域时，其中并没有 a 标识符，因此进行了正常的 LHS 表示法查找。

o2 的作用域、foo(..) 的作用域和全局作用域都没有找到标识符 a，因此当 a = 2 执行时，自动创建了一个全局变量（因为是非严格模式）

with  这种将对象及其属性放进一个作用域并同时分配标识符的行为很让人费解。

另外一个不推荐使用 eval(..) 和 with 的原因是会被严格模式所影响（限制）。with 被完全禁止，而在保留核心功能的前提下，间接或非安全的使用 eval(..) 也被禁止了。

性能

 eval(..) 和 with 会在运行时修改或创建新的作用域，以此来欺骗其他书写时定义的词法作用域。

你可能会问，那又怎样呢？如果它们能实现更复杂的功能，并且代码更具有扩展性，难道不是非常好的功能吗？答案是否定的。

JavaScript 引擎会在编译阶段进行数项的性能优化。其中有些优化依赖于能够根据代码的词法进行静态分析，并预先确定所有变量和函数的定义位置，才能在执行过程中快速的找到标识符。

但如果引擎在代码中发现了 eval(..) 或 with ，它只能简单的假设关于标识符位置的判断都是无效的，因为无法在词法分析阶段明确知道 eval(..) 会接收到什么代码，这些代码会如何对作用域进行修改，也无法知道传递给 with 用来创建新词法作用域的对象的内容到底是什么。

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

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

总结

词法作用域意味着作用域是由书写代码时函数声明的位置来决定的。编译的词法分析阶段基本能够知道全部标识符在哪里以及是如何声明的，从而能够预测在执行过程中如何对它们进行查找。

JavaScript 中有两个机制可以“欺骗”词法作用域：eval(..) 和 with。前者可以对一段包含一个或多个声明的“代码”字符串进行演算，并借此来修改已经存在的词法作用域（在运行时）。后者本质上是通过将一个对象的引用当作作用域来处理，将对象的属性当作作用域中的标识符来处理，从而创建了一个新的词法作用域（同样是在运行时）。

这两个机制的副作用是引擎无法在编译时对作用域查找进行优化，因为引擎只能谨慎地认为这样的优化是无效的。使用这其中任何一个机制都将导致代码运行变慢。不要使用它们。