在服务器端，当处理sql、influxdb或mongo等外部脚本时，eval非常有用。可以在运行时进行自定义验证，而无需重新部署服务。

例如，具有以下元数据的成就服务

{ "568ff113-abcd-f123-84c5-871fe2007cf0": { "msg_enum": "quest/registration", "timely": "all_times", "scope": [ "quest/daily-active" ], "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" LIMIT 1`", "validator": "valid > 0", "reward_external": "ewallet", "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/registration:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/registration\"}`" }, "efdfb506-1234-abcd-9d4a-7d624c564332": { "msg_enum": "quest/daily-active", "timely": "daily", "scope": [ "quest/daily-active" ], "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" WHERE time >= '${today}' ${ENV.DAILY_OFFSET} LIMIT 1`", "validator": "valid > 0", "reward_external": "ewallet", "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/daily-active:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/daily-active\"}`" } }

然后允许，

通过json中的文字字符串直接注入对象/值，对于模板文本很有用 可以用作比较，比如我们制定规则如何验证CMS中的任务或事件

缺点:

如果没有完全测试，代码中的错误可能会破坏服务中的内容。 如果黑客可以在您的系统上编写脚本，那么您就完蛋了。 验证脚本的一种方法是将脚本的散列保存在安全的地方，以便在运行之前检查它们。

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

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

底线

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

略为详细

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

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

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

推理

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

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

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

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

Eval是编译的补充，编译用于代码模板。我所说的模板是指编写一个简化的模板生成器，生成有用的模板代码，从而提高开发速度。

我写了一个框架，其中开发人员不使用EVAL，但他们使用我们的框架，反过来，该框架必须使用EVAL来生成模板。

通过以下方法可以提高EVAL的性能:您必须返回一个函数，而不是执行脚本。

var a = eval("3 + 5");

它应该被组织成

var f = eval("(function(a,b) { return a + b; })");

var a = f(3,5);

缓存肯定会提高速度。

Chrome也允许调试这样的功能非常容易。

在安全性方面，是否使用eval几乎没有什么区别。

First of all, the browser invokes the entire script in a sandbox. Any code that is evil in EVAL, is evil in the browser itself. The attacker or anyone can easily inject a script node in DOM and do anything if he/she can eval anything. Not using EVAL will not make any difference. It is mostly poor server-side security that is harmful. Poor cookies validation or poor ACL implementation on the server causes most attacks. A recent Java vulnerability, etc. was there in Java's native code. JavaScript was and is designed to run in a sandbox, whereas applets were designed to run outside a sandbox with certificates, etc. that lead to vulnerabilities and many other things. Writing code for imitating a browser is not difficult. All you have to do is make a HTTP request to the server with your favourite user agent string. All testing tools mock browsers anyway; if an attacker want to harm you, EVAL is their last resort. They have many other ways to deal with your server-side security. The browser DOM does not have access to files and not a user name. In fact nothing on the machine that eval can give access to.

如果您的服务器端安全性足够坚固，任何人都可以从任何地方进行攻击，那么您就不应该担心EVAL。正如我提到的，如果EVAL不存在，攻击者就有很多工具来入侵你的服务器，而不管你浏览器的EVAL能力如何。

Eval只适用于生成一些模板，根据事先没有使用的内容进行复杂的字符串处理。例如，我更喜欢

"FirstName + ' ' + LastName"

而不是

"LastName + ' ' + FirstName"

作为我的显示名，它可以来自数据库，并且不是硬编码的。