17370845950

严格模式是强制性运行约束，使隐性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() 都会让它失效。

为什么普通模式会“坑人”？两个典型场景对比

严格模式的价值，就藏在那些你没意识到的“自动兜底”行为里：

• 未声明变量直接赋值：普通模式下 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 字符串都符合规则。