严格模式通过报错暴露隐患而非避免错误：禁用with、只读/不可配属性赋值删除报TypeError、参数重名报SyntaxError、arguments与形参解绑；须首行写"use strict"（双引号无空格）；全局或函数级启用；this在全局函数中为undefined；eval不污染外层作用域。
JavaScript 严格模式（"use strict"）本身不主动“避免错误”，它只是让某些原本静默失败或危险的行为立刻抛出明确错误，迫使你直面问题。启用后，很多低级错误会提前暴露，而不是等到运行时崩溃或产生难以追踪的副作用。
严格模式下哪些操作会直接报错
这是最值得立即检查的地方：一旦启用，以下行为不再容忍
-
with语句被完全禁止，使用即SyntaxError - 给只读属性赋值（如
Object.defineProperty(obj, 'x', { writable: false })后再obj.x = 1）抛TypeError - 删除不可配置属性（
delete obj.x）失败时不再静默返回false，而是抛TypeError - 函数参数名重复（
function foo(a, a) { }）触发SyntaxError -
arguments不再与形参自动绑定——修改arguments[0]不再影响a，反之亦然
如何正确启用严格模式
必须是脚本或函数体内的**第一行可执行语句**，且字符串字面量必须是 "use strict"（不能带空格、单引号、模板字符串）
- 全局启用：
"use strict";\nfunction foo() { ... }—— 整个脚本生效，但注意模块（.mjs或type="module"）默认就是严格模式 - 函数级启用：
function bar() {\n "use strict";\n // 仅此处生效\n}—— 更安全，避免污染全局作用域 - 禁止写法：
"use strict "（尾部空格）、'use strict'（单引号）、`use strict`（模板字面量）均无效
严格模式对 this 和 eval 的关键影响
这两处最容易引发隐蔽 bug，严格模式强制行为更可预测
- 非严格模式下，全局函数中
this指向window（浏览器）或global（Node.js）；严格模式下为undefined，避免意外污染全局对象 -
eval在严格模式下不引入新变量到外层作用域，且其内部声明的变量、函数仅在eval内部有效 -
eval不能通过字符串动态创建arguments或caller，防止反调试和代码混淆滥用
为什么有些项目不加 "use strict" 也能跑
因为很多错误在非严格模式下只是“不做事”或“做错事”，比如静默忽略重复属性、允许八进制字面量（010 → 8）、delete 失败不报错。这些不会中断执行，但会让逻辑偏离预期——尤其在大型协作项目中，这类隐性缺陷比明确报错更难定位。
真正容易被忽略的是：严格模式无法“补救”已存在的逻辑错误，它只放大语言层面的不安全用法。如果你的代码依赖 with 或动态 eval 注入变量，加了严格模式反而会直接崩，这时得先重构，而不是删掉 "use strict"。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
