严格模式不是必须加，而是用于提前暴露变量泄漏、静默失败、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语句：动态作用域导致无法静态分析，几乎所有现代引擎已禁用，严格模式直接报语法错误 - 八进制字面量（
0100o10取代，旧写法在严格模式下报SyntaxError - 重复参数名：
function foo(a, a) { }→SyntaxError，避免覆盖和混淆 - 删除不可配置属性：
delete Object.prototype.toString→TypeError，防止破坏内置行为
010严格模式对 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" 反而多余甚至干扰调试。
