严格模式通过添加"use strict"指令启用，使JavaScript代码在更严格的规则下运行，防止隐式全局变量、禁用with语句、明确this指向，并提升代码安全性与可维护性；它默认集成于ES模块和类中，是现代JavaScript开发的推荐实践。
JavaScript的严格模式，在我看来，它就像是语言给自己加的一道“紧箍咒”，初听起来可能觉得束缚，但深入了解后，你会发现这道“咒语”实则在默默守护着代码的健康和可预测性。简单来说，它是一种选择性的执行环境，让JS代码在运行时遵循一套更严苛的规则，目的是为了规避那些容易踩坑的设计，提升整体的代码质量。它强制开发者编写更规范、更健壮的代码，将一些静默的错误转化为显式的抛出，从而帮助我们更早地发现和修复问题。
解决方案
要启用严格模式，你只需要在脚本文件或函数体的顶部加上一行字符串字面量
"use strict";。这行代码本身不是一个语句，而是一个指令，它会告诉JavaScript引擎以严格模式解析和执行当前作用域的代码。如果放在全局作用域，整个脚本都会进入严格模式；如果放在函数内部，则只有该函数及其内部的代码以严格模式运行。这种粒度控制挺有意思的，它允许你在不影响整个项目的前提下，逐步引入严格模式。
严格模式引入了一系列限制和修改，这些都是为了弥补JavaScript早期设计中的一些“宽松”之处。比如，它会阻止你创建隐式的全局变量——这是我个人觉得最实用的一点，因为太多低级错误都源于不小心遗漏了
var、
let或
const。在非严格模式下，
foo = "bar";会悄悄地创建一个全局变量
foo，这简直是bug的温床；但在严格模式下，这会直接抛出一个
ReferenceError，让你立即知道哪里出了问题。
再比如，严格模式下，函数中的
this值不再默认指向全局对象（
window或
global），而是保持为
undefined，除非它被明确地绑定。这对于理解和编写面向对象的JavaScript代码至关重要，也避免了许多意料之外的副作用。此外，严格模式还禁用了
with语句，这个语句在非严格模式下虽然能用，但它的性能和可读性问题简直是噩梦。还有八进制字面量（比如
010表示十进制的8）也被禁止了，因为它们常常与十进制混淆，导致难以察觉的错误。它还对
arguments对象和函数参数做了一些限制，例如不允许给
arguments赋值，也不允许函数参数重名，这些都是为了让代码的行为更可预测。
// 全局严格模式
"use strict";
// 此时整个脚本都处于严格模式下
function strictFunction() {
// 函数内部的严格模式
"use strict";
// 只有这个函数内部的代码处于严格模式
// ...
}
function nonStrictFunction() {
// 这个函数不在严格模式下
// ...
}
// 示例：隐式全局变量
// "use strict";
// testVar = 10; // 在严格模式下会抛出 ReferenceError
// 示例：this的绑定
function showThis() {
console.log(this);
}
// showThis(); // 在严格模式下输出 undefined，非严格模式下输出 window/global启用严格模式能带来哪些实际好处？
在我看来，启用严格模式带来的好处是多方面的，并且是实实在在的。首先，也是最直接的，它能帮助我们更早地发现代码中的潜在错误。那些在非严格模式下会被默默“吞掉”的错误，比如给不可写属性赋值、删除不可配置的属性，或者像前面提到的隐式全局变量，在严格模式下都会立即抛出错误。这就像给你的代码加了一个强力的静态分析工具，只不过它是在运行时起作用，能帮你省去不少调试时间。
其次，严格模式提高了代码的安全性与健壮性。通过消除一些不安全的语言特性，比如
with语句，以及限制
eval函数在创建变量方面的能力，它让代码的行为变得更加可预测，减少了潜在的安全漏洞。对于团队协作而言，这尤其重要，因为大家都在一个更规范、更少“陷阱”的环境中工作，代码质量自然会提升。
另外，一个常常被忽视但非常重要的好处是，严格模式有助于JavaScript引擎进行优化。当引擎知道代码处于严格模式下时，它能做出一些非严格模式下无法进行的假设，从而执行更有效的优化。这可能意味着你的代码运行得更快。最后，它也是拥抱现代JavaScript特性的一种方式。你可能会发现，ES模块（
import/
export）和类（
class）这些现代JS语法，默认就是以严格模式运行的，你甚至不需要手动添加
"use strict";。这其实是在告诉我们，严格模式是未来的趋势，提前适应它，能让你更好地过渡到更现代的JavaScript开发范式。
严格模式对现有JavaScript代码可能产生哪些影响？
在我的开发经验中，将严格模式引入到已有的、特别是那些历史悠久的JavaScript项目中，确实需要一些细致的考量和工作。最直接的影响就是可能导致现有代码“破碎”。因为严格模式改变了许多语言行为，之前在非严格模式下能正常运行的代码，一旦进入严格模式，很可能会因为触发了新的限制而抛出错误。
例如，如果你有代码不小心创建了隐式全局变量，或者在某个函数内部
this的绑定依赖于默认的全局对象，那么在严格模式下，这些地方就会报错。这需要开发者对代码库有比较深入的理解，才能定位并修复这些问题。我记得有一次，我们尝试在旧项目中启用严格模式，结果一下子冒出了几十个错误，其中大部分都是
ReferenceError和
TypeError，这确实是一个不小的挑战。
因此，在大型项目中引入严格模式，通常需要一个逐步的、有策略的迁移过程。你不能指望一次性将所有代码都切换到严格模式。更好的做法是：
- 从新代码开始：确保所有新编写的模块、文件或函数都默认使用严格模式。
-
逐步重构旧代码：挑选一些相对独立的模块或功能，将其重构为严格模式兼容。这通常意味着要明确声明所有变量，确保
this
的正确绑定，并移除任何被严格模式禁用的特性。 - 充分的测试：每次引入严格模式到一部分代码后，都必须进行彻底的单元测试和集成测试，确保没有引入新的bug。这可能是一个漫长但值得的过程。
这就像给一辆老旧的汽车进行现代化改造，你不能指望一蹴而就，得一步步来，确保每一步都稳妥，才能最终让它跑得更快、更安全。
严格模式与ES模块化、类等现代JavaScript特性有何关联？
严格模式和ES模块化、类这些现代JavaScript特性之间，存在着一种非常紧密的、甚至是共生共荣的关系。这并不是巧合，而是语言设计者有意为之的。
一个最显著的特点就是：ES模块（ECMAScript Modules）和JavaScript类（Classes）默认就是以严格模式运行的。这意味着，当你使用
import和
export语法来组织代码时，或者当你定义一个
class时，你不需要在文件或类定义的顶部显式地写上
"use strict";，因为它们天生就处于严格模式的环境中。
这在我看来，是一个非常明智的设计决策。它有效地推动了JavaScript生态系统向更规范、更健壮的方向发展。通过将严格模式作为现代语法的默认行为，它降低了开发者在采用这些新特性时的心智负担。你不需要额外去考虑“我这里要不要加
use strict”，因为当你选择使用模块或类时，你已经自动进入了一个更安全、更可预测的编程环境。
这同时也传递了一个信号：严格模式是JavaScript语言未来的标准实践。它不再是一个可选项，而是一个默认的、推荐的编程范式。这种关联性也使得那些从旧项目迁移到现代JavaScript的开发者，能够更自然地适应严格模式带来的行为变化，因为它已经成为了新代码的“底色”。当你习惯了在模块和类中编写严格模式的代码后，你自然也会倾向于在其他地方也使用它，从而整体提升项目的代码质量和可维护性。这是一种潜移默化的引导，也是语言演进的巧妙之处。
