代码生成。我最近写了一个叫做Hyperbars的库，它在虚拟世界和把手之间架起了桥梁。它通过解析句柄模板并将其转换为超脚本来实现这一点。超脚本首先作为字符串生成，在返回它之前，eval()将其转换为可执行代码。我发现eval()在这种特殊情况下与邪恶完全相反。

基本上从

<div>
    {{#each names}}
        <span>{{this}}</span>
    {{/each}}
</div>

这个

(function (state) {
    var Runtime = Hyperbars.Runtime;
    var context = state;
    return h('div', {}, [Runtime.each(context['names'], context, function (context, parent, options) {
        return [h('span', {}, [options['@index'], context])]
    })])
}.bind({}))

eval()的性能在这种情况下也不是问题，因为您只需要解释一次生成的字符串，然后多次重用可执行输出。

如果您好奇的话，您可以看到代码生成是如何实现的。

如果真的需要，eval也不是坏事。但是我偶然发现的99.9%的eval使用是不需要的(不包括setTimeout的东西)。

对我来说，邪恶不是性能问题，甚至不是安全问题(好吧，间接地，两者都是)。所有这些不必要的eval使用都增加了维护的难度。重构工具被抛弃了。搜索代码是困难的。这些评估的意想不到的影响是很多的。

让我们看看真正的人:

现在每个主流浏览器都有一个内置的控制台，你想成为黑客的人可以使用它来调用任何值的任何函数-为什么他们会麻烦使用eval语句-即使他们可以? 如果编译2000行JavaScript需要0.2秒，那么如果我计算4行JSON，性能会下降多少?

即使克罗克福德对“eval是邪恶的”的解释也很软弱。

eval是邪恶的，eval函数是最被滥用的功能 JavaScript。避免它

正如克罗克福德自己可能会说的那样:“这种说法往往会产生非理性的神经症。别买它。”

理解eval并知道它什么时候可能有用更重要。例如，eval是评估软件生成的服务器响应的明智工具。

顺便说一句:Prototype.js直接调用eval 5次(包括在evalJSON()和evalResponse()中)。jQuery在parseJSON中使用它(通过函数构造函数)。

当你相信消息来源时。

在JSON的情况下，它或多或少很难篡改源代码，因为它来自你控制的web服务器。只要JSON本身不包含用户上传的数据，使用eval就没有什么大的缺点。

在所有其他情况下，在将用户提供的数据提供给eval()之前，我将竭尽全力确保它符合我的规则。

我倾向于遵循Crockford关于eval()的建议，并完全避免使用它。即使是看起来需要它的方法也不需要。例如，setTimeout()允许您传递一个函数而不是eval。

setTimeout(function() {
  alert('hi');
}, 1000);

即使它是一个可信的源，我也不会使用它，因为JSON返回的代码可能是乱码，最好的情况下可能会产生一些不稳定的东西，最坏的情况下可能会暴露一些不好的东西。

唯一需要使用eval()的情况是需要动态地运行JS。我说的是你从服务器异步下载的JS…

.．.10次中的9次你都可以通过重构来避免这种情况。