我想到两点:

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

这可能存在安全风险，它具有不同的执行范围，并且效率非常低，因为它为代码的执行创建了一个全新的脚本环境。更多信息请参见这里: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元素更可靠。)

如果您正在执行用户提交的代码，除了可能存在的安全问题之外，大多数情况下，有一种更好的方法，无需在每次执行时都重新解析代码。匿名函数或对象属性可以替代eval的大部分用途，而且更安全、更快。

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

编辑:正如Benjie的评论所建议的，这似乎不再是chrome v108的情况，似乎chrome现在可以处理已计算脚本的垃圾收集。

VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV

垃圾收集

浏览器的垃圾收集不知道被评估的代码是否可以从内存中删除，所以它只是一直存储它，直到页面被重新加载。 如果你的用户只是在你的页面上停留很短的时间，这不是太糟糕，但这可能是一个webapp的问题。

下面是演示该问题的脚本

https://jsfiddle.net/CynderRnAsh/qux1osnw/

document.getElementById("evalLeak").onclick = (e) => {
  for(let x = 0; x < 100; x++) {
    eval(x.toString());
  }
};

像上面代码这样简单的代码会导致存储少量内存，直到应用程序死亡。 当被赋值的脚本是一个巨大的函数，并且在间隔时间调用时，情况会更糟。