我看到有人提倡不要使用eval，因为这是邪恶的，但我也看到同样的人动态地使用Function和setTimeout，所以他们在幕后使用eval:D

顺便说一句，如果你的沙盒不够确定(例如，如果你在一个允许代码注入的网站上工作)，eval是你的最后一个问题。安全的基本规则是所有输入都是邪恶的，但对于JavaScript，甚至JavaScript本身也可能是邪恶的，因为在JavaScript中，你可以覆盖任何函数，你只是不能确定你使用的是真正的函数，所以，如果恶意代码在你之前启动，你不能相信任何JavaScript内置函数:D

现在这篇文章的尾声是:

如果你真的需要它(80%的时间不需要eval)，并且你确定你在做什么，只使用eval(或更好的Function;))，闭包和OOP覆盖了80/90%的情况，其中eval可以使用另一种逻辑替换，其余是动态生成的代码(例如，如果你正在编写解释器)，正如你已经说过的评估JSON(这里你可以使用Crockford安全评估;))

当你相信消息来源时。

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

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

底线

如果你创建或净化了你评估的代码，它永远不会是邪恶的。

略为详细

如果在服务器上使用不是由开发人员创建或未经过开发人员处理的客户端提交的输入运行Eval是邪恶的。

如果在客户端上运行Eval，即使使用客户端制作的未经处理的输入，它也不是邪恶的。

显然，您应该始终清理输入，以便对代码使用的内容有一定的控制。

推理

客户端可以运行任何他们想要的代码，即使开发人员没有编写这些代码;这不仅适用于被求值的对象，而且适用于对eval本身的调用。

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

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

我的使用eval: import的例子。

通常的做法。

var components = require('components');
var Button = components.Button;
var ComboBox = components.ComboBox;
var CheckBox = components.CheckBox;
...
// That quickly gets very boring

但是在eval和一个小helper函数的帮助下，它得到了更好的外观:

var components = require('components');
eval(importable('components', 'Button', 'ComboBox', 'CheckBox', ...));

Importable可能看起来像这样(此版本不支持导入具体成员)。

function importable(path) {
    var name;
    var pkg = eval(path);
    var result = '\n';

    for (name in pkg) {
        result += 'if (name !== undefined) throw "import error: name already exists";\n'.replace(/name/g, name);
    }

    for (name in pkg) {
        result += 'var name = path.name;\n'.replace(/name/g, name).replace('path', path);
    }
    return result;
}