严格模式是强制性运行约束，使隐性bug显性化；需在脚本或函数顶部以"use strict"字符串启用，分全局和函数级两种作用域，禁用八进制字面量、限制eval/arguments、强化错误检测。
JavaScript 严格模式不是语法糖，而是一套强制性的运行约束——它让原本“悄悄失败”的代码立刻报错，把隐性 bug 变成显性错误。
怎么开启严格模式？两种写法，作用域完全不同
严格模式必须出现在脚本或函数的**最顶部**，且只能是字符串字面量 "use strict"（单引号、双引号均可，但不能加括号或分号干扰）。
-
全局严格模式：整个文件生效，适用于现代模块化项目（如 ES6 modules 默认就是严格模式，无需手动加）
"use strict"; a = 10; // ReferenceError: a is not defined
-
函数级严格模式：只对当前函数及其嵌套函数生效，适合渐进式迁移旧代码
function safeFn() { "use strict"; delete Object.prototype.toString; // TypeError: Cannot delete property 'toString' of function Object() }
⚠️ 注意："use strict" 必须是作用域内第一个可执行语句；前面若有注释、空行、甚至 console.log() 都会让它失效。
为什么普通模式会“坑人”？两个典型场景对比
严格模式的价值，就藏在那些你没意识到的“自动兜底”行为里：
javascript-typescript-typescript-scaffold
下载
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
立即学习“Java免费学习笔记（深入）”；
-
未声明变量直接赋值：普通模式下
a = 42会默默挂到window.a（浏览器）或global.a（Node.js），污染全局；严格模式下直接抛ReferenceError。 -
this绑定失控：普通模式中fn.call(null)会让this指向全局对象，导致意外改写window.name；严格模式下this就是null或undefined，不会自动升级。 -
重复参数名：普通模式允许
function foo(a, a) { }（第二个a覆盖第一个），严格模式直接报SyntaxError。
哪些地方容易踩坑？兼容性和误用提醒
严格模式本身不改变语言核心逻辑，但会暴露底层细节和历史包袱：
-
八进制字面量被禁用：
010在严格模式下是SyntaxError，必须写成0o10或parseInt("10", 8)。 -
保留字变关键字：
class、enum、export等不能再当变量名，否则报SyntaxError。 -
eval和arguments受限：不能用eval动态创建变量，arguments不再自动映射形参变化，避免意外副作用。 - 浏览器兼容性没问题：IE10+、Chrome13+、Firefox4+、Safari5.1+ 全部支持；老浏览器直接忽略该字符串，无任何副作用。
真正容易被忽略的是：严格模式无法“局部关闭”，也不能靠条件判断动态启用。一旦在某个作用域启用了，它就贯穿到底——哪怕你只是想在某个函数里试一试，也得确保它里面所有子函数、回调、eval 字符串都符合规则。
