当没有宏时，Eval对于代码生成很有用。

举个愚蠢的例子，如果你正在编写一个Brainfuck编译器，你可能想要构造一个函数，它以字符串的形式执行指令序列，并对它进行eval以返回一个函数。

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

在Chrome (v28.0.1500.72)中调试时，我发现如果变量没有在产生闭包的嵌套函数中使用，则它们不会绑定到闭包。我想，这是JavaScript引擎的优化。

但是:当eval()在导致闭包的函数中使用时，外部函数的所有变量都被绑定到闭包中，即使它们根本没有被使用。如果有人有时间测试内存泄漏是否会由此产生，请在下面给我留言。

下面是我的测试代码:

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is visible in debugger
            eval("1");
        })();
    }

    evalTest();
})();

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is NOT visible in debugger
            var noval = eval;
            noval("1");
        })();
    }

    evalTest();
})();

(function () {
    var noval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();    // Variable "unused" is NOT visible in debugger
            noval("1");
        })();
    }

    evalTest();
})();

我想在这里指出的是，eval()不一定指向本机eval()函数。这完全取决于函数的名称。因此，当使用别名调用本机eval()时(说var noval = eval;然后在内部函数noval(expression);)中，当表达式引用了应该是闭包的一部分但实际上不是的变量时，表达式的求值可能会失败。

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

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

Eval()并不坏。或者，如果是的话，它是邪恶的，就像反射、文件/网络I/O、线程和IPC在其他语言中的“邪恶”一样。

如果，出于您的目的，eval()比手动解释更快，或者使您的代码更简单，或更清楚……那么你应该使用它。如果两者都不是，那么你就不应该这么做。就这么简单。