严格模式强制变量声明、禁用隐式全局变量、使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)重新赋值、删除不可配置属性等。
典型错误示例: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 规则或检查打包产物是否保留了严格指令,比运行时靠运气发现更可靠。