你不知道的 eval

前言

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 代码的确调试起来比较麻烦，但也不是彻底没有办法。能够在 eval 建立的代码末尾添加一行 "//@ sourceURL=name" 就能够给这段代码命名（浏览器会特殊对待这种特殊形式的注释），这样它就会出如今 Sources 面板上，而后就能够设置断点调试了。

真香警告

虽然你们嘴上说不要用，可是 eval 用起来倒是真香。

笔者作过的项目中，曾经为了让 HTML 模板（应该说是一套页面主题）也具有动态解析内联表达式的能力，用了 data-eval 将 js 代码存储在 dom 节点，而后渲染时用 with 语句（另外一个 JS “毒瘤”，如今严格模式下已经禁用 with 了，rip...）将 data 加到做用域链上，再用 eval 解析执行。实现出来的效果相似这样：

<div data-eval="data.count = data.count + 1">
    {{data.count}}
</div>
复制代码

渲染出来的结果是 eval 计算后的值。

不少库和框架都用了 eval 实现各类黑魔法。早期的有用 eval 解析 json 的，好比 Douglas Crockford 的 json2.js（真香！）。到后来，各类 MVVM 框架也用 new Function 这个 eval 的好基友，来实现模板内嵌表达式的计算，好比 Vue 和 avalon。要达到的效果和笔者上面介绍的例子大体相同，不一样的是这些 MVVM 框架还须要先解析模板，基于正则表达式提取出 new Function 的参数。

甚至不能用 eval 的时候，也要本身造一个 eval 出来。好比小程序上就不能使用 eval 和 new Function，那么若是想动态注入并执行代码的话，须要绕一个大弯，从编译原理出发，自行实现一个 JS parser。

总结

关于 eval，笔者我的的见解是，你能够不去用它，但要去了解它。写这篇文章的目的也不是为了推荐你们使用 eval。就平时的业务开发而言，eval 几乎没有用武之地。但在一些特殊场合，eval 就像一枚核弹，无往不利。

---

参考连接：

1. Global eval. What are the options?
2. Knockout, Vue 和 AvalonJS 等 MVVM 框架实现中是否用到 eval 或 Function?
3. eval() isn’t evil, just misunderstood
4. A new V8 is coming, Node.js performance is changing.
5. V8: Behind the Scenes (February Edition feat. A tale of TurboFan)