在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: 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;
}

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对于Webassembly-Javascript互操作非常有用。虽然在您的页面中包含WASM代码可以直接调用的预先制作的脚本当然是理想的，但有时这是不可行的，您需要从Webassembly语言(如c#)传入动态Javascript来真正完成您需要做的事情。

在这种情况下，它也是安全的，因为您可以完全控制传入的内容。好吧，我应该说，这并不比使用c#编写SQL语句更安全，也就是说，无论何时使用用户提供的数据来生成脚本，都需要谨慎地执行(正确转义字符串等)。但在这种情况下，它在互操作场景中有一个明确的位置，远非“邪恶”。

只要可以确定代码的源代码来自您或实际用户，就没有理由不使用eval()。尽管他可以操纵发送到eval()函数的内容，但这并不是一个安全问题，因为他能够操纵网站的源代码，因此可以改变JavaScript代码本身。

所以…何时不使用eval()?Eval()只应该在第三方有可能更改它的情况下才使用。比如拦截客户端和服务器之间的连接(但如果这是一个问题，请使用HTTPS)。你不应该用eval()来解析别人写的代码，比如在论坛上。

底线

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

略为详细

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

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

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

推理

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