我正在编写一些JavaScript代码来解析用户输入的函数(用于类似电子表格的功能)。解析完公式后，我可以将其转换为JavaScript并在其上运行eval()以产生结果。
然而，我总是避免使用eval()，因为它是邪恶的(而且，无论正确与否，我一直认为它在JavaScript中更邪恶，因为要计算的代码可能会被用户更改)。
那么，什么时候可以使用它呢?
当前回答
我倾向于遵循Crockford关于eval()的建议，并完全避免使用它。即使是看起来需要它的方法也不需要。例如，setTimeout()允许您传递一个函数而不是eval。
setTimeout(function() {
alert('hi');
}, 1000);
即使它是一个可信的源，我也不会使用它，因为JSON返回的代码可能是乱码，最好的情况下可能会产生一些不稳定的东西，最坏的情况下可能会暴露一些不好的东西。
其他回答
Eval()并不坏。或者，如果是的话，它是邪恶的，就像反射、文件/网络I/O、线程和IPC在其他语言中的“邪恶”一样。
如果，出于您的目的，eval()比手动解释更快，或者使您的代码更简单，或更清楚……那么你应该使用它。如果两者都不是，那么你就不应该这么做。就这么简单。
如果你可以完全控制传递给eval函数的代码，那么使用它是可以的。
如果真的需要，eval也不是坏事。但是我偶然发现的99.9%的eval使用是不需要的(不包括setTimeout的东西)。
对我来说，邪恶不是性能问题，甚至不是安全问题(好吧，间接地，两者都是)。所有这些不必要的eval使用都增加了维护的难度。重构工具被抛弃了。搜索代码是困难的。这些评估的意想不到的影响是很多的。
当没有宏时，Eval对于代码生成很有用。
举个愚蠢的例子，如果你正在编写一个Brainfuck编译器，你可能想要构造一个函数，它以字符串的形式执行指令序列，并对它进行eval以返回一个函数。
代码生成。我最近写了一个叫做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()的性能在这种情况下也不是问题，因为您只需要解释一次生成的字符串，然后多次重用可执行输出。
如果您好奇的话，您可以看到代码生成是如何实现的。
