我想到两点:

安全性(但只要您自己生成要计算的字符串，这可能就不是问题) 性能:除非要执行的代码是未知的，否则无法进行优化。(关于javascript和性能，当然是Steve Yegge的演示)

这是一篇谈论eval的好文章，以及它如何不是一种邪恶: http://www.nczonline.net/blog/2013/06/25/eval-isnt-evil-just-misunderstood/

I’m not saying you should go run out and start using eval() everywhere. In fact, there are very few good use cases for running eval() at all. There are definitely concerns with code clarity, debugability, and certainly performance that should not be overlooked. But you shouldn’t be afraid to use it when you have a case where eval() makes sense. Try not using it first, but don’t let anyone scare you into thinking your code is more fragile or less secure when eval() is used appropriately.

随着带有JavaScript编译器的下一代浏览器问世，这可能会成为一个更大的问题。通过Eval执行的代码在这些新浏览器上的表现可能不如JavaScript的其他部分。应该有人来做侧写。

这并不总是一个坏主意。以代码生成为例。我最近写了一个叫做Hyperbars的库，它在虚拟世界和把手之间架起了桥梁。它通过解析句柄模板并将其转换为虚拟dom使用的超脚本来实现这一点。超脚本首先作为字符串生成，在返回它之前，eval()将其转换为可执行代码。我发现eval()在这种特殊情况下与邪恶完全相反。

基本上从

<div>
    {{#each names}}
        <span>{{this}}</span>
    {{/each}}
</div>

这个

(function (state) {
    var Runtime = Hyperbars.Runtime;
    var context = state;
    return h('div', {}, [Runtime.each(context['names'], context, function (context, parent, options) {
        return [h('span', {}, [options['@index'], context])]
    })])
}.bind({}))

eval()的性能在这种情况下不是问题，因为您只需要解释一次生成的字符串，然后多次重用可执行输出。

如果您好奇的话，您可以看到代码生成是如何实现的。

Eval并不总是邪恶的。有些时候，这是非常合适的。

然而，eval在当前和历史上都被那些不知道自己在做什么的人过度使用。不幸的是，这包括编写JavaScript教程的人，在某些情况下，这确实会产生安全后果——或者，更常见的是，简单的错误。所以，我们在eval上加的问号越多越好。任何时候你使用eval你都需要检查你正在做的事情，因为你可能会用一种更好，更安全，更干净的方式来做。

举一个非常典型的例子，设置id存储在变量'potato'中的元素的颜色:

eval('document.' + potato + '.style.color = "red"');

如果上面这类代码的作者对JavaScript对象工作的基本原理有所了解，他们就会意识到可以使用方括号来代替字面上的点名称，从而消除了eval的需要:

document[potato].style.color = 'red';

.．.这更容易阅读，也更少潜在的错误。

(但是，那些/真正/知道自己在做什么的人会说:

document.getElementById(potato).style.color = 'red';

这比直接从文档对象中访问DOM元素更可靠。)

主要是，维护和调试要困难得多。就像goto一样。您可以使用它，但它会使发现问题变得更加困难，对稍后可能需要进行更改的人来说也更加困难。