前言

eval() 是 JavaScript 中一个非常有用的函数，它可以一段代码字符串动态执行。然而各种编码规范和最佳实践都强烈抵制 eval，几乎将 eval 打入了死牢，大牛 Douglas Crockford 也在《JavaScript 语言精粹》一书中将 eval 视为 JavaScript 中糟粕。这篇文章将带大家重新认识这个函数，知道为什么不用它，以及为什么不得不用它。

eval 是什么

在分析 eval 的利弊前，首先来认识一下它。在不清楚一项技术的情况下，就对它做出武断地评价，是有失公允的。

eval 是全局对象上的一个函数，会把传入的字符串当做 JavaScript 代码执行。如果传入的参数不是字符串，它会原封不动地将其返回。eval 分为直接调用和间接调用两种，通常间接调用的性能会好于直接调用。

直接调用时，eval 运行于其调用函数的作用域下；

var context = 'outside';
(function(){
  var context = 'inside';
  return eval('context');
})();

// return 'inside'

而间接调用时，eval 运行于全局作用域。

var context = 'outside';
(function(){
  var context = 'inside';
  geval = eval;
  return geval('context');
  
  // 下面两种也属于间接调用
  // return eval.call(null, 'context');
  // return (1, eval)('context');
})();

// return 'outside'

因此，间接调用时，eval 并不会修改调用函数作用域内的任何东西。JS 解释器有 fast path 和 slow path 两种模式，当直接调用 eval 时，解释器处于 slow path。因为此时作用域是不可控的，需要监听整个作用域，不能应用 v8 的一些编译优化，相应的编译效率也会比 fast path 低。

为什么不用 eval

大家抵制 eval 的原因主要是以下几个原因：

1. 降低性能。具体原因上文已经提到了。网上一些文章甚至说 eval() 会拖慢性能 10 倍。
2. 安全问题。因为它的动态执行特性，给被求值的字符串赋予了太大的权力，于是大家担心可能因此导致 XSS 等攻击。
3. 调试困难。eval 就像一个黑盒，其执行的代码很难进行断点调试。

鉴于以上各种原因，很多人说 eval 是 evil（魔鬼）。另外，eval 还有一些难兄难弟，比如 new Function, setTimeout, setInterval。它们也具备执行一段代码字符串的能力。
究其本质原因，还是因为 JS 赋予这个方法的权限太大了，作为新手很难驾驭它，如果对 eval 没有很好地理解，很容易写出问题来。这有点像 C 语言中 goto 语句，同样是因为权限太大而被封杀的典范。

被误解的 eval

事实上，eval 一直在被误解，它可能是最强大的一个 JavaScript 函数，但却因为一些人的误用，而被开发者们打入了冷宫。接下来，我来根据上述被质疑最多的几个点，给出一点自己的看法。

1. 关于 eval 会拖慢性能 10 倍这个点，出自 Mozila 工程师的演讲 “Know Your Engines - How to make your JavaScript Fast”。
   

这是一个发布于 2011 年的演讲，时至今日，JS 引擎早已做了各种优化。我们来测试现在的 JS 引擎中，eval 的实际性能。依然使用上图作为测试用例，测试环境为 node v8.11.1，设 N 的值为 10000。

Benchmark 跑出的数据来看，当 N = 10000 时，用了 eval 的 function 执行性能，相比没有 eval 的情况，慢了 3 倍多。
将 N 的值设为 1000000，eval 的性能下降到 8 倍。

从测试结果可知，eval 的确会拖慢函数执行性能，而且随着函数规模增大，性能也越慢。但是在一般情况下（N < 1000000），性能差异并没有 10 倍那么夸张。

2. 关于 eval 会导致 XSS 攻击这点，问题并不在 eval，而在数据源。如果数据源本身就是不可靠的，即便你不用 eval，也可能出现 XSS。

3. 至于第三点，eval...