我正在编写一些JavaScript代码来解析用户输入的函数(用于类似电子表格的功能)。解析完公式后，我可以将其转换为JavaScript并在其上运行eval()以产生结果。
然而，我总是避免使用eval()，因为它是邪恶的(而且，无论正确与否，我一直认为它在JavaScript中更邪恶，因为要计算的代码可能会被用户更改)。
那么，什么时候可以使用它呢?
当前回答
底线
如果你创建或净化了你评估的代码，它永远不会是邪恶的。
略为详细
如果在服务器上使用不是由开发人员创建或未经过开发人员处理的客户端提交的输入运行Eval是邪恶的。
如果在客户端上运行Eval，即使使用客户端制作的未经处理的输入，它也不是邪恶的。
显然，您应该始终清理输入，以便对代码使用的内容有一定的控制。
推理
客户端可以运行任何他们想要的代码，即使开发人员没有编写这些代码;这不仅适用于被求值的对象，而且适用于对eval本身的调用。
其他回答
Eval()并不坏。或者，如果是的话，它是邪恶的，就像反射、文件/网络I/O、线程和IPC在其他语言中的“邪恶”一样。
如果，出于您的目的，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()的性能在这种情况下也不是问题，因为您只需要解释一次生成的字符串，然后多次重用可执行输出。
如果您好奇的话，您可以看到代码生成是如何实现的。
如果你可以完全控制传递给eval函数的代码，那么使用它是可以的。
如果真的需要，eval也不是坏事。但是我偶然发现的99.9%的eval使用是不需要的(不包括setTimeout的东西)。
对我来说，邪恶不是性能问题，甚至不是安全问题(好吧，间接地，两者都是)。所有这些不必要的eval使用都增加了维护的难度。重构工具被抛弃了。搜索代码是困难的。这些评估的意想不到的影响是很多的。
底线
如果你创建或净化了你评估的代码，它永远不会是邪恶的。
略为详细
如果在服务器上使用不是由开发人员创建或未经过开发人员处理的客户端提交的输入运行Eval是邪恶的。
如果在客户端上运行Eval，即使使用客户端制作的未经处理的输入，它也不是邪恶的。
显然，您应该始终清理输入，以便对代码使用的内容有一定的控制。
推理
客户端可以运行任何他们想要的代码，即使开发人员没有编写这些代码;这不仅适用于被求值的对象，而且适用于对eval本身的调用。
