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

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

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

如果你可以完全控制传递给eval函数的代码，那么使用它是可以的。

Eval并不邪恶，只是被滥用了。

如果您创建了代码，或者可以信任它，那就没问题。 人们一直在说用户输入对eval不重要。嗯，有点~

如果用户输入到服务器，然后返回到客户端，那么这些代码就被用于eval而没有被净化。恭喜你，你打开了潘多拉的盒子，用户数据可以发送给任何人。

根据eval的位置不同，许多网站都使用spa, eval可以让用户更容易地访问应用程序内部，否则就不容易。现在他们可以做一个虚假的浏览器扩展，可以磁带到评估，并再次窃取数据。

我只是想知道你用评估有什么用。当您可以简单地创建方法来做这类事情，使用对象或类似的事情时，生成代码并不理想。

这是一个很好的使用eval的例子。 您的服务器正在读取您创建的swagger文件。许多URL参数是以{myParam}格式创建的。因此，您希望读取url，然后将它们转换为模板字符串，而不必进行复杂的替换，因为您有许多端点。你可以这样做。 注意，这是一个非常简单的例子。

const params = { id: 5 };

const route = '/api/user/{id}';
route.replace(/{/g, '${params.');

// use eval(route); to do something

我想花点时间谈谈你的问题的前提——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()并不比任何其他可能为您节省时间的函数更邪恶。

什么时候JavaScript的eval()不是邪恶的?

我总是不鼓励使用eval。几乎总是有更干净和可维护的解决方案可用。Eval甚至对于JSON解析也不需要。Eval增加了维护的难度。道格拉斯·克罗克福德(Douglas Crockford)这样的大师并不赞同这一点，这不无道理。

但我发现了一个应该使用它的例子:

当你需要传递表达式时。

例如，我有一个函数，为我构造了一个通用的google.maps.ImageMapType对象，但我需要告诉它配方，它应该如何从缩放和坐标参数构造tile URL:

my_func({
    name: "OSM",
    tileURLexpr: '"http://tile.openstreetmap.org/"+b+"/"+a.x+"/"+a.y+".png"',
    ...
});

function my_func(opts)
{
    return new google.maps.ImageMapType({
        getTileUrl: function (coord, zoom) {
            var b = zoom;
            var a = coord;
            return eval(opts.tileURLexpr);
        },
        ....
    });
}

我相信eval对于客户端web应用程序来说是一个非常强大的功能，并且是安全的。和JavaScript一样安全，但JavaScript不安全。:-)安全问题本质上是服务器端的问题，因为现在，使用像Firebug这样的工具，你可以攻击任何JavaScript应用程序。