JavaScript严格模式是什么？有何优势？

JavaScript严格模式是一种通过启用更严格语法和错误检查机制来提升代码质量与安全性的语言特性，它能有效解决隐式全局变量污染、静默失败的非法操作、this绑定混乱、危险或易混淆语法（如arguments.callee、八进制字面量、参数重名）以及eval和arguments作用域泄漏等长期困扰开发者的隐患；开启后让潜在错误在运行时立即暴露为明确异常，显著增强代码可预测性、可维护性和可调试性，尤其在现代模块化开发中已成为默认实践——理解并正确使用它，是写出健壮、专业JavaScript代码的关键一步。

严格模式开启后变量必须声明才能使用

不加 "use strict" 时，给未声明的变量赋值会自动创建全局变量，容易污染全局作用域、掩盖拼写错误。开启后直接报 ReferenceError。

常见错误现象：name = "Alice" 在非函数作用域或普通函数中执行，没报错但悄悄挂到 window.name（浏览器）或 global.name（Node.js）上。

实操建议：

• 在脚本顶部或函数体第一行写 "use strict"（注意：必须是字符串字面量，且不能有前置语句）
• 避免在 with 块内启用严格模式（语法不允许）
• 模块（.mjs 或 import/ export 的文件）默认启用严格模式，无需手动加

禁止静默失败的赋值操作

严格模式让原本“看似成功”的非法操作立刻抛错，比如给不可写属性赋值、给只读全局对象（如 undefined、NaN、Infinity）重新赋值、删除不可配置属性等。

典型错误示例：delete Object.prototype 在非严格模式下返回 false 却不报错；严格模式下直接抛 TypeError。

实操建议：

• 检查旧代码中是否依赖 delete 返回布尔值做判断——严格模式下该行为不可靠
• this 在非对象上下文（如普通函数调用）中不再绑定到全局对象，而是 undefined，避免意外修改全局状态
• 避免在构造函数外使用 new.target，它在严格/非严格下行为一致，但仅在严格模式下对箭头函数有效（实际箭头函数无 new.target）

限制存在安全隐患或易混淆的语法

严格模式禁用了一些歧义大、维护性差或已被废弃的特性，例如：

常见被禁用项：

• arguments.callee 和 arguments.caller —— 无法再通过 arguments 反向获取函数本身，消除递归匿名函数的隐式依赖
• 八进制字面量（如 010）—— 改为必须写 0o10 或 0x10，避免数字开头零引发误解
• 函数参数名重复（function foo(a, a) { }）—— 严格模式下直接语法错误，非严格模式仅保留最后一个值
• eval 和 arguments 不能作为标识符（var eval = 1 报错）

这些限制不是为了“多此一举”，而是让代码行为更可预测、更容易被静态分析工具识别问题。

严格模式对 eval 和 arguments 的隔离更彻底

非严格模式下，eval 内部声明的变量会泄漏到外层作用域；arguments 对象与形参保持“双向绑定”（改 arguments[0] 会同步影响 a）。

严格模式切断这两类隐式耦合：

• eval("var x = 1"); console.log(x); → 报 ReferenceError（x 不泄露）

• function foo(a) {
    "use strict";
    arguments[0] = 2;
    console.log(a); // 仍输出原值，如传入 1 则输出 1
  }

这点在调试或重构带 eval 的老代码时特别关键——你不能再假设 eval 是“作用域黑洞”，它现在真正沙箱化了。

严格模式不是银弹，但它把很多“运行时不报错却逻辑错”的坑提前暴露出来。最容易被忽略的是：模块默认严格、IIFE 中漏写 "use strict" 导致子作用域仍处于宽松状态、以及第三方库未启用时带来的行为不一致。上线前用 ESLint 开启 strict 规则或检查打包产物是否保留了严格指令，比运行时靠运气发现更可靠。

本篇关于《JavaScript严格模式是什么？有何优势？》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！