这是一篇谈论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.

如果你知道你在什么环境中使用它，它并不一定那么糟糕。

如果您的应用程序使用eval()从XMLHttpRequest返回到您自己的站点的某个JSON中创建一个对象，该对象是由受信任的服务器端代码创建的，那么这可能不是问题。

不可信的客户端JavaScript代码无论如何也做不了那么多。只要你执行eval()的对象来自一个合理的源，就没问题。

我想到两点:

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

不恰当地使用eval会打开你的 注入攻击代码 调试可能更具挑战性 (没有行号等) 经过评估的代码执行速度较慢(没有机会编译/缓存经过评估的代码)

编辑:正如杰夫·沃尔登在评论中指出的那样，第三条在今天已经不像2008年那么正确了。然而，虽然可能会发生一些已编译脚本的缓存，但这将只局限于没有修改地重复计算的脚本。更可能的情况是，您正在计算的脚本每次都经历了轻微的修改，因此无法缓存。我们就说someeval代码执行得更慢。

需要记住的一件事是，您可以经常使用eval()在其他受限制的环境中执行代码——阻塞特定JavaScript函数的社交网站有时可以通过在eval块中分解它们来愚弄它们

eval('al' + 'er' + 't(\'' + 'hi there!' + '\')');

因此，如果你想运行一些JavaScript代码，否则它可能是不允许的(Myspace，我看着你…)，那么eval()可能是一个有用的技巧。

然而，由于上面提到的所有原因，你不应该在你自己的代码中使用它，在那里你有完全的控制权——这是没有必要的，最好把它归到“棘手的JavaScript hacks”架子上。

这大大降低了您对安全性的信心。