17370845950

严格模式不是必须加，而是用于提前暴露变量泄漏、静默失败、this绑定混乱等问题；它禁止未声明赋值、使独立函数调用的this为undefined、禁用with和八进制字面量等危险语法，并限制eval和arguments行为。

JavaScript 严格模式（"use strict"）不是“必须加”，而是当你遇到变量意外泄漏、静默失败、this 绑定混乱或难以调试的诡异行为时，它能帮你提前暴露问题——而不是等线上崩了才去翻 console。

为什么赋值给未声明变量会报错？

非严格模式下，a = 42（没用 var/let/const）会自动在全局对象（如 window）上挂载属性，极易污染全局、引发冲突；严格模式直接抛出 ReferenceError: a is not defined。

常见场景：

• 拼错变量名（userNmae = "Alice"），非严格模式默默创建新变量，后续读取 userName 为 undefined，难定位
• 函数内忘记写 var，导致意外闭包或内存泄漏

"use strict";
function test() {
  userName = "Alice"; // ❌ 报错：ReferenceError
  let userName = "Alice"; // ✅ 正确
}

为什么 this 在普通函数里变成 undefined？

非严格模式中，独立调用函数（如 foo()）时，this 指向全局对象（window 或 globalThis），容易误读数据或意外修改全局状态；严格模式让 this 保持为 undefined，强制你明确绑定。

典型踩坑：

• 事件回调或定时器中直接调用方法，this 意外丢失上下文
• 把对象方法传给第三方库（如 arr.map(obj.method)），this 不再指向原对象

"use strict";
function logThis() {
  console.log(this); // undefined，而非 window
}
logThis();

哪些语法在严格模式下被禁止？

这些限制不是为了“增加难度”，而是封掉历史上被滥用、易出错、或阻碍引擎优化的写法：

• with 语句：动态作用域导致无法静态分析，几乎所有现代引擎已禁用，严格模式直接报语法错误
• 八进制字面量（010）：已被 0o10 取代，旧写法在严格模式下报 SyntaxError
• 重复参数名：function foo(a, a) { } → SyntaxError，避免覆盖和混淆
• 删除不可配置属性：delete Object.prototype.toString → TypeError，防止破坏内置行为

严格模式对 eval 和 arguments 的影响

这两者是非严格模式下最隐蔽的性能杀手和调试噩梦：

• eval 在严格模式中不引入新变量到外层作用域，且无法访问或修改 arguments.callee
• arguments 不再与形参自动同步（即改 arguments[0] 不再影响 a），避免副作用；也不能用 arguments.callee 实现递归（鼓励用命名函数表达式）

"use strict";
function demo(a) {
  arguments[0] = 99;
  console.log(a); // 仍输出原值，不会变成 99
}

严格模式不是银弹，但它把很多“运行时不报错但逻辑错”的陷阱，变成“一写就报错”的确定性反馈。真正容易被忽略的是：它必须放在脚本顶部或函数体第一行，否则无效；且模块（.mjs 或 import 加载的脚本）默认启用严格模式——这点常被遗忘，导致局部加 "use strict" 反而多余甚至干扰调试。