严格模式非强制但能提前暴露undefined赋值、静默失败、this指向混乱等问题；它使只读属性赋值、删除不可配置属性等行为抛TypeError，禁用with语句，函数参数重复报SyntaxError，且this在独立调用时为undefined。
JavaScript 严格模式不是“必须用”，而是当你遇到 undefined 意外被赋值、静默失败的错误、this 指向混乱、重复参数或属性报错不明确等问题时，它能帮你提前暴露问题。
严格模式下哪些常见错误会直接抛出异常
非严格模式里很多错误只是“没效果”，比如给只读属性赋值、删除不可配置属性、使用保留字作变量名——全都不报错。严格模式把这些都变成 TypeError 或 SyntaxError：
-
"use strict"后给NaN、undefined、Infinity赋值 →TypeError - 函数参数名重复（如
function foo(a, a) {}）→SyntaxError（解析阶段就卡住） - 对象字面量中重复键名（
{a: 1, a: 2}）在严格模式下仍是合法的，但某些引擎早期版本会报错；更典型的是delete不可配置属性 →TypeError -
with语句直接被禁用，写就报SyntaxError
"use strict" 的作用域和启用方式
它只对当前作用域生效，不是全局开关：
- 写在脚本顶部 → 整个脚本启用（注意：必须是第一行可执行代码，前面只能有注释）
- 写在函数体第一行 → 仅该函数启用（包括其内部嵌套函数）
- 不能写在
if块或任何条件逻辑里，否则会被忽略（例如if (true) {"use strict"}无效） - 模块（
.mjs或type="module"的 script）默认启用严格模式，无需手动加
严格模式如何改变 this 的行为
这是最易踩坑的一点：非严格模式下，函数独立调用时 this 指向 window（浏览器）或 global（Node.js）；严格模式下直接是 undefined：
function foo() { return this; }
foo(); // 非严格 → window；严格 → undefined
这会让依赖隐式绑定的旧代码立刻崩，但也迫使你明确 call/apply/bind 或箭头函数的使用意图。类方法、事件回调、定时器回调中若漏了绑定，严格模式能更快暴露问题。
为什么现代项目常不显式写 "use strict"
因为构建工具（如 Babel、TypeScript）默认输出严格模式代码，且 ES6+ 的模块、类、箭头函数等语法天然运行在严格上下文中。手动加反而可能因位置错误失效（比如被压缩工具误删、被拼接脚本污染）。真正需要关注的，是理解严格模式所禁止的行为背后的设计意图——比如避免意外全局变量、防止静默失败、统一 this 绑定逻辑。这些原则比那行字符串更重要。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
