我认为评价被证明是正确的情况将是罕见的。”你更有可能认为它是合理的，而不是在实际合理的情况下使用它。

安全问题最为人所知。但也要注意JavaScript使用JIT编译，这与eval的工作效果很差。Eval有点像编译器的黑匣子，JavaScript需要能够提前(在某种程度上)预测代码，以便安全正确地应用性能优化和范围。在某些情况下，性能影响甚至会影响eval之外的其他代码。

如果你想了解更多: https://github.com/getify/You-Dont-Know-JS/blob/master/scope%20%26%20closures/ch2.md#eval

Eval很少是正确的选择。虽然在许多情况下，您可以通过将脚本连接在一起并动态运行来完成需要完成的任务，但您通常可以使用更强大和可维护的技术:关联数组符号(obj["prop"]与obj.prop相同)、闭包、面向对象技术、函数技术—请使用它们。

虽然在许多情况下，您可以通过将脚本连接在一起并动态运行来完成需要完成的任务，但您通常可以使用更强大且可维护的技术。Eval很少是正确的选择。:关联数组表示法(obj["prop"]与obj.prop相同)，闭包，面向对象技术，函数技术-请使用它们。

我认为评价被证明是正确的情况将是罕见的。”你更有可能认为它是合理的，而不是在实际合理的情况下使用它。

安全问题最为人所知。但也要注意JavaScript使用JIT编译，这与eval的工作效果很差。Eval有点像编译器的黑匣子，JavaScript需要能够提前(在某种程度上)预测代码，以便安全正确地应用性能优化和范围。在某些情况下，性能影响甚至会影响eval之外的其他代码。

如果你想了解更多: https://github.com/getify/You-Dont-Know-JS/blob/master/scope%20%26%20closures/ch2.md#eval

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

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

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

我想花点时间谈谈你的问题的前提——eval()是“邪恶的”。“邪恶”这个词，在编程语言的使用者中，通常意味着“危险”，或者更准确地说，“能够用一个看起来简单的命令造成很多伤害”。那么，什么时候可以使用危险的东西呢?当你知道危险是什么，并采取适当的预防措施时。

首先，让我们看看使用eval()的危险。就像其他事情一样，可能有许多小的隐患，但是两个大的风险——eval()被认为是邪恶的原因——是性能和代码注入。

Performance - eval() runs the interpreter/compiler. If your code is compiled, then this is a big hit, because you need to call a possibly-heavy compiler in the middle of run-time. However, JavaScript is still mostly an interpreted language, which means that calling eval() is not a big performance hit in the general case (but see my specific remarks below). Code injection - eval() potentially runs a string of code under elevated privileges. For example, a program running as administrator/root would never want to eval() user input, because that input could potentially be "rm -rf /etc/important-file" or worse. Again, JavaScript in a browser doesn't have that problem, because the program is running in the user's own account anyway. Server-side JavaScript could have that problem.

说到你的具体情况。根据我的理解，您自己生成字符串，所以假设您小心地不允许生成像“rm -rf something-important”这样的字符串，就没有代码注入风险(但请记住，在一般情况下很难确保这一点)。此外，如果你在浏览器中运行，那么我相信代码注入的风险是相当小的。

至于性能，您必须将其与编码的便捷性进行权衡。我的观点是，如果要解析公式，不妨在解析期间计算结果，而不是运行另一个解析器(eval()内的解析器)。但是使用eval()编码可能更容易，而且性能上的影响可能不太明显。在这种情况下，看起来eval()并不比任何其他可能为您节省时间的函数更邪恶。