严格模式是执行约束开关，不改变语法能力但提升错误检测：未声明赋值报错、this为undefined、禁止with等；需首行声明，作用域限定于脚本或函数，es6模块自动启用。
严格模式不是新语法，而是执行约束开关
它不改变 javaScript 的能力，只改变引擎对代码的“容忍度”：原本静默忽略的问题，会直接报错。比如未声明就赋值——非严格模式下自动挂到 window 上；严格模式下立刻抛出 ReferenceError: username is not defined。
- 它是一条字面量语句：
"use strict";，不是命令也不是函数调用，浏览器不支持时会被忽略（无副作用） - 作用域分两级：整个脚本顶部写，全局生效；函数体第一行写，仅该函数内生效
- ES6 模块（
.mjs或import/export文件）和class内部自动启用严格模式，无需手动加
哪些错误会被提前暴露？重点看这三类典型场景
严格模式真正价值在于把“运行时才崩”的问题，变成“一写就报错”或“一跑就停”，大幅缩短调试链路。
- 隐式全局变量：
count = 42;在非严格模式下创建window.count；严格模式下直接报错 - this 绑定更可控：普通函数独立调用时，
this是undefined而非window，避免意外修改全局对象 - 非法操作显式失败：给不可写属性赋值、删除不可配置属性、重复定义对象键名（
{x:1, x:2}）、重复函数参数（function foo(a, a) {}）都会立即报TypeError或语法错误
为什么现在还要手动加”use strict”？
虽然现代构建工具（如 webpack、vite）和模块系统默认启用，但仍有真实场景依赖显式声明：
- 老项目中大量
.js文件未转模块，仍走 script 标签加载，必须靠"use strict";触发 - 某些库源码（如早期版本的 Lodash、jquery 插件）会在 IifE 开头手动开启，以保证内部逻辑安全
- 调试时临时加在某段函数里，快速验证是否因非严格行为导致异常（比如
arguments.callee被禁用） - 注意：不能写在条件语句里——
if (true) {"use strict";}无效，必须是脚本/函数的**物理首行**
"use strict"; function test() { "use strict"; undeclared = "boom"; // ReferenceError this.x = 1; // 正常，因为 this 是 undefined，赋值被忽略（但不会报错） return this; } test(); // 返回 undefined，而非 window容易被忽略的兼容性与限制细节
严格模式不是万能补丁，有些行为变化反而会让旧代码直接失效，上线前必须验证：
立即学习“Java免费学习笔记（深入）”；
-
with语句被完全禁止，任何含with(obj) { ... }的代码会直接 SyntaxError - 八进制字面量（
010）非法，必须写成0o10或0x10 -
eval变得更干净：它内部声明的变量不会泄露到外层作用域，但也不能通过eval动态创建函数参数或函数名 - 某些保留字（
class、enum、export、import、super）在严格模式下不能再当变量名，否则 SyntaxError
严格模式的价值不在“多做了什么”，而在“少容忍了什么”。最常踩的坑，其实是忘了它只对**紧邻作用域**生效——一个文件里写了，不代表所有 import 进来的模块也受约束；一个函数开了，不代表它的回调函数自动继承。这点在混合使用 CommonJS 和动态 eval 时尤其容易翻车。