我正在编写一些JavaScript代码来解析用户输入的函数(用于类似电子表格的功能)。解析完公式后，我可以将其转换为JavaScript并在其上运行eval()以产生结果。
然而，我总是避免使用eval()，因为它是邪恶的(而且，无论正确与否，我一直认为它在JavaScript中更邪恶，因为要计算的代码可能会被用户更改)。
那么，什么时候可以使用它呢?
当前回答
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"
作为我的显示名，它可以来自数据库，并且不是硬编码的。
其他回答
如果真的需要，eval也不是坏事。但是我偶然发现的99.9%的eval使用是不需要的(不包括setTimeout的东西)。
对我来说，邪恶不是性能问题，甚至不是安全问题(好吧，间接地，两者都是)。所有这些不必要的eval使用都增加了维护的难度。重构工具被抛弃了。搜索代码是困难的。这些评估的意想不到的影响是很多的。
至于客户端脚本，我认为安全性问题是一个有争议的问题。加载到浏览器中的所有内容都受到操作的影响，因此应该这样对待。当有更简单的方法来执行JavaScript代码和/或操作DOM中的对象(例如浏览器中的URL栏)时，使用eval()语句的风险为零。
javascript:alert("hello");
如果有人想操纵他们的DOM，我说swing away。防止任何类型的攻击的安全性应该始终是服务器应用程序的责任。
从实用主义的角度来看，在可以用其他方法完成任务的情况下，使用eval()没有任何好处。但是，在某些特定的情况下应该使用eval。当这样做时，它绝对可以在没有任何破坏页面的风险的情况下完成。
<html>
<body>
<textarea id="output"></textarea><br/>
<input type="text" id="input" />
<button id="button" onclick="execute()">eval</button>
<script type="text/javascript">
var execute = function(){
var inputEl = document.getElementById('input');
var toEval = inputEl.value;
var outputEl = document.getElementById('output');
var output = "";
try {
output = eval(toEval);
}
catch(err){
for(var key in err){
output += key + ": " + err[key] + "\r\n";
}
}
outputEl.value = output;
}
</script>
<body>
</html>
我看到有人提倡不要使用eval，因为这是邪恶的，但我也看到同样的人动态地使用Function和setTimeout，所以他们在幕后使用eval:D
顺便说一句，如果你的沙盒不够确定(例如，如果你在一个允许代码注入的网站上工作)，eval是你的最后一个问题。安全的基本规则是所有输入都是邪恶的，但对于JavaScript，甚至JavaScript本身也可能是邪恶的，因为在JavaScript中，你可以覆盖任何函数，你只是不能确定你使用的是真正的函数，所以，如果恶意代码在你之前启动，你不能相信任何JavaScript内置函数:D
现在这篇文章的尾声是:
如果你真的需要它(80%的时间不需要eval)，并且你确定你在做什么，只使用eval(或更好的Function;))，闭包和OOP覆盖了80/90%的情况，其中eval可以使用另一种逻辑替换，其余是动态生成的代码(例如，如果你正在编写解释器)，正如你已经说过的评估JSON(这里你可以使用Crockford安全评估;))
我想花点时间谈谈你的问题的前提——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函数的代码，那么使用它是可以的。
推荐文章
- 给一个数字加上st, nd, rd和th(序数)后缀
- 如何以编程方式触发引导模式?
- setTimeout带引号和不带括号的区别
- 在JS的Chrome CPU配置文件中，'self'和'total'之间的差异
- 用javascript检查输入字符串中是否包含数字
- 如何使用JavaScript分割逗号分隔字符串?
- 在Javascript中~~(“双波浪号”)做什么?
- 谷歌chrome扩展::console.log()从后台页面?
- 未捕获的SyntaxError:
- [].slice的解释。调用javascript?
- jQuery日期/时间选择器
- 我如何预填充一个jQuery Datepicker文本框与今天的日期?
- 数组的indexOf函数和findIndex函数的区别
- jQuery添加必要的输入字段
- Access-Control-Allow-Origin不允许Origin < Origin >
