仅在调试中“使用严格”？答案

【问题标题】："use strict" only in debug?仅在调试中“使用严格”？
【发布时间】：2012-06-11 19:55:38
【问题描述】：

我想知道当我完成编程并将我的 JavaScript 文档发布给任何人查看时，是否真的需要包含 "use strict"。我喜欢使用它，因为它可以检查我的编码是否正确。

那么，当我向公众发布我的 JavaScript 文件时，我应该包括还是只删除使用 "use strict"？

我问的原因是为了节省 JavaScript 文件的空间。

【问题讨论】：

【解决方案1】：

我发现了两个关于在生产中使用strict mode 的意见：

没有理由在您的生产代码中使用“use strict”。没有性能提升（不久前通过 V8 团队和 Brendan 进行了验证），我也不需要用户的 VM 进行额外的检查。仅保留开发，在构建期间将其剥离。这样您还可以避免您引用的串联问题。

还有：

可能没有性能提升，但也没有性能损失。在生产中，比在开发中更重要的是，您希望确保自己注意到错误。最大限度地减少代码的开发和生产版本之间的更改是能够快速有效地调试问题的关键。是的，它在开发过程中有所帮助，但没有理由将其从生产代码中移除。

当然，12b 和 "use strict" 的重量不会改变任何事情。

【讨论】：

有趣的报价。关于这个问题，这似乎 OP 已经决定节省的 12 个字节是值得的。我很难相信，特别是如果它需要手动删除而不是作为构建过程的一部分。有一些严格的模式更改不向后兼容，因此在这些情况下删除声明性可能会破坏代码。但是，如果支持非严格的实现，那么这些更改可能（希望）不会以不兼容的方式使用。
@amnotiam。非严格模式不支持哪些严格模式功能？或者我在那里完全失去了你……？你用strict-mode吗？
是的，我确实使用严格，但我最近一直在做更多的服务器端，所以没有兼容性问题。可能有几个，但首先想到的是函数的调用上下文。在严格模式下，它可以是任何值，包括原语，甚至是null 或undefined，而在非严格模式下，您可以保证它始终是一个对象，默认为undefined。另一个变化是arguments 对象映射到形式参数。严格来说，它们是完全不同的值。更改参数不会影响arguments 对象，反之亦然。

【解决方案2】：

"use strict"; 行占文件的 13 个字节。我建议这甚至不太可能接近文件大小的 1%。

如果您担心带宽问题，请使用众多压缩工具之一来减小文件大小，同时在服务器端使用 gzip 压缩。手动删除 13 个字节是一种错误的经济方式。

究竟哪个缩小器可能取决于您的代码，但here are some suggestions。

【讨论】：

【解决方案3】：

当然这是一个微优化，但如果你将（比如 25 个）JS 模块连接在一起，那么突然就变成了 250 字节。

在高流量应用程序中部署到生产环境，例如每分钟 1000 次点击，如果您的构建删除了 'use strict';s，那么每年可以防止 130+ Gb 的流量

我确信这会在 AWS 上节省几美元...

除了不值得花时间之外，我还没有看到一个令人信服的论点来让它继续投入生产。可能不是，但如果您已经有一个构建系统，并且知道如何以最小的努力完成它，为什么不呢？

【讨论】：

因为 gzip 会比 250 字节少很多
我想知道为什么许多 JS 最小化器没有（提供选项）去掉它？
这是一个非常错误的论点。假设网络带宽为 1 美元/GB（极高），那么任何提供 每年 50 亿次请求的网站的所有者都不会担心每年 130 美元。
@abhidivekar “每年 50 亿次请求”甚至没有那么高。谷歌确实做了数万亿美元。如果像 uglifyJS 这样的工具可以做到这一点，甚至可以将包大小减少几口，我看不出那会是什么坏事。我再说一遍，是的，这将是一个微优化。

【解决方案4】：

我目前建议您删除任何用于生产的代码中的“use strict”（并仅在调试中使用它）。

但是，我不会为了使文件更小而将其删除。我删除它的原因是因为它目前似乎对 JavaScript 在执行时的实际性能有负面影响。希望这最终会改变，但现在出于性能原因我会省略它。

【讨论】：