我正在阅读一些关于在 JavaScript 中使用严格模式的内容，一般来说，这个想法似乎是将一组更严格的规则强加给编码器，以确保 JS 引擎可以更好地优化代码。它几乎感觉就像是 Visual Basic 中“Option Explicit”的 JavaScript 等价物。
如果这基本上是对我的代码应用严格模式的净效果，那么性能差异是否值得出于习惯而不是逐个应用？除了代码稳定性之外，还有其他值得考虑的优势吗？
我希望将严格模式应用于我的脚本的一些关键原因是什么？
【问题讨论】：
好吧，严格模式代码当然可以表现得更好，因为它消除了使优化变得更加困难的问题，例如，从我的头脑中：
with 语句（如果不是不可能的话，真的很难优化）。delete varName;)eval 不会将变量/函数声明引入本地范围。arguments.callee 被移除，（难以优化（例如函数内联））arguments 对象索引命名属性不再动态映射到命名形式参数。【讨论】：
我认为 John Resig http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/ 已经很好地说明了使用它的原因，而且似乎 Firefox 将支持它，http://whereswalden.com/2010/09/08/new-es5-strict-mode-support-now-with-poison-pills/，因此至少对于库而言，查看它可能很有用。
但是，基本上，它是为了帮助防止一些常见的编程错误，但是对于一些失去eval 的人来说可能是不使用它的理由，而且对我来说没有未命名的匿名函数会很困难，但是，任何可以帮助减少错误可能是值得的。
【讨论】：
eval，唯一改变的是在严格模式代码上的 direct eval 调用会构建一个新的变量环境，意味着所有的变量和函数声明都不会影响封闭范围，它们是在这个新环境中进行的（这显然有助于引擎进行代码优化）。
我不知道性能是否值得，但我猜你的结果可能会有所不同。我想这取决于你的脚本。但这并不意味着要成为重点，而是减少您维护代码的时间。因此，任何能够为您节省时间（和金钱）维护代码并使其更快的东西都是黄金。
我已得到纠正，遗憾的是，它不包括强类型。研究人员花了很多年的时间来强制键入以在编译时检测错误，现在我们必须相信我们的代码是好的，或者通过手动或单元测试来验证它。恕我直言，在很多地方，单元测试所花费的时间通常都很稀少，不应该花在编译器可以完成的事情上。
【讨论】：