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

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

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

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

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

这可能存在安全风险，它具有不同的执行范围，并且效率非常低，因为它为代码的执行创建了一个全新的脚本环境。更多信息请参见这里:eval。

不过，它非常有用，适度使用可以添加许多很好的功能。

JavaScript引擎在编译阶段执行了许多性能优化。其中一些可以归结为能够在代码lexx时对其进行静态分析，并预先确定所有变量和函数声明的位置，以便在执行期间解析标识符时花费更少的精力。

但是，如果引擎在代码中发现了eval(..)，它本质上必须假设它对标识符位置的所有感知都可能是无效的，因为它在lexlexation时无法确切地知道您可以传递给eval(..)来修改词法作用域的哪些代码，或者您可以传递给对象的内容来创建一个新的词法作用域以供参考。

换句话说，悲观地说，如果eval(..)存在，它所做的大多数优化都是毫无意义的，因此它根本不执行优化。

这就解释了一切。

参考:

https://github.com/getify/You-Dont-Know-JS/blob/master/scope%20&%20closures/ch2.md#eval

https://github.com/getify/You-Dont-Know-JS/blob/master/scope%20&%20closures/ch2.md#performance

编辑:正如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());
  }
};

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

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元素更可靠。)