严格模式强制变量声明、禁用隐式全局变量、使this在非对象调用时为undefined、禁止arguments.callee等不安全语法，并隔离eval和arguments作用域。
严格模式开启后变量必须声明才能使用
不加 "use strict" 时，给未声明的变量赋值会自动创建全局变量，容易污染全局作用域、掩盖拼写错误。开启后直接报 ReferenceError。
常见错误现象：name = "Alice" 在非函数作用域或普通函数中执行，没报错但悄悄挂到 window.name（浏览器）或 global.name（node.js）上。
实操建议：
- 在脚本顶部或函数体第一行写
"use strict"（注意：必须是字符串字面量，且不能有前置语句） - 避免在
with块内启用严格模式（语法不允许） - 模块（
.mjs或import/export的文件）默认启用严格模式，无需手动加
禁止静默失败的赋值操作
严格模式让原本“看似成功”的非法操作立刻抛错，比如给不可写属性赋值、给只读全局对象（如 undefined、NaN、Infinity）重新赋值、删除不可配置属性等。
立即学习“Java免费学习笔记（深入）”；
典型错误示例：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 规则或检查打包产物是否保留了严格指令，比运行时靠运气发现更可靠。