JavaScript严格模式深度解析与实践

一、为什么需要严格模式

JavaScript诞生之初以“灵活易上手”为设计目标，语言层面保留了相当多的“宽容”设计：给未声明的变量赋值不会报错，而是自动在全局对象上创建属性；对不可写的属性赋值、删除不可配置的属性，引擎只是默默忽略；全局作用域中的普通函数调用，this默认指向全局对象。

这些设计在小型脚本中似乎“省事”，但随着前端工程规模不断扩大，它们逐渐演变成难以定位的隐患来源：一个拼写错误的变量名会悄悄污染全局作用域；一次看似成功的赋值实际上根本没有生效。为了解决这类问题，ECMAScript 5（2009年）引入了严格模式（Strict Mode），以一种“向后兼容的可选择加入（opt-in）”机制，让开发者主动为代码选择一套更严谨的解析与执行规则。

二、严格模式的本质与设计哲学

从引擎视角看，严格模式本质上是切换了JavaScript的解析与执行规则子集：禁用一批历史遗留的、容易引发错误的语言特性，并把一部分原本“静默失败”的操作转变为抛出明确的语法错误或运行时错误。

值得注意的是它的启用方式——字符串字面量 “use strict”：

• 它不是一条关键字语句，而是一个表达式语句。这种设计的目的是向后兼容：不支持严格模式的旧引擎会把它当作一条无害的表达式语句直接跳过，不会抛出语法错误；
• 它必须是纯粹的字符串字面量，不能通过变量拼接、函数调用等方式动态构造，例如 "use " + "strict" 不会启用严格模式；
• 只有出现在指令序言（即脚本或函数体最顶部的语句序列）中时才有效。

三、启用方式与作用范围

3.1 三种启用场景

脚本级：将 “use strict” 放在脚本文件第一行，整个脚本进入严格模式：

"use strict";
// 以下所有代码处于严格模式
count = 1; // ReferenceError: count is not defined

函数级：放在函数体第一条语句的位置，仅对该函数及其内部嵌套函数生效，不影响脚本中其他代码：

function strictFn() {
  "use strict";
  // 函数内部为严格模式
}
function sloppyFn() {
  // 非严格模式
}

默认严格上下文：ES6的模块（Module）与类（Class）的代码块天生运行在严格模式下，无需显式声明。这也是现代前端工程中严格模式事实上的默认形态——当项目以模块方式组织代码时，严格模式已经无处不在。

3.2 位置要求与常见陷阱

• “use strict” 之前可以有空行、注释，但不能有任何可执行代码。一旦前面出现了变量声明或其他语句，它就退化成一条普通表达式语句，完全失去效果：

var debug = true;
"use strict"; // 不是第一条语句，声明无效

• 它不能写在条件块里“按需启用”。严格模式是编译期的语法约束，不存在运行时动态开关：

if (isProduction) {
  "use strict"; // 这只是一条字符串表达式，不会切换模式
}

• 在多脚本简单拼接的场景下，需注意严格模式的“泄漏”与“失效”问题：把一个带全局声明的严格脚本拼在另一个非严格脚本之前，会让后者也进入严格模式；反之则可能使声明失去第一行位置。更稳妥的做法是给每段代码包一层立即执行函数（IIFE），把严格模式的边界收缩到函数内部。

四、核心语法变化逐条解析

先通过一张速查表建立整体印象，再逐条展开：

变化点	非严格模式	严格模式
给未声明变量赋值	隐式创建全局变量	抛出 ReferenceError
全局函数中的 this	指向全局对象	undefined
删除不可配置属性	静默失败	抛出 TypeError
with 语句	可用	语法错误
重名参数	允许	语法错误
0开头八进制字面量	允许	语法错误
arguments.callee	可用	抛出 TypeError
eval 内 var 声明	泄漏到外层作用域	仅在 eval 内部生效

4.1 强制变量声明，杜绝隐式全局变量

非严格模式下，直接给未声明的变量赋值会在全局对象上创建属性，这是污染全局作用域的头号元凶——拼写错误、漏写声明都会悄无声息地制造出全局变量。严格模式下，此类操作直接抛出 ReferenceError：

"use strict";
userName = "test"; // ReferenceError: userName is not defined

把错误暴露在开发阶段，而不是留到线上以数据串扰的形式出现，这正是严格模式“将问题提前”的典型体现。同时，对普通变量名使用 delete 在严格模式下属于语法错误，进一步堵住了误用 delete 的口子。

4.2 this 指向的变化

严格模式下，全局作用域中的普通函数调用，this 不再指向全局对象，而是 undefined：

"use strict";
function checkThis() {
  console.log(this); // undefined
}
checkThis();

这一变化的核心价值在于防御构造函数的误用。非严格模式下，忘记写 new 直接调用“构造函数”时，this 指向全局对象，this.x = ... 会把属性挂到全局上，既污染环境又返回 undefined，产生难以追踪的连锁问题。严格模式下，同样的代码会在赋值处抛出 TypeError，让错误当场暴露。

另需留意 call/apply 的行为差异：严格模式下，若显式以 null 或 undefined 作为 this 传入，它们不会被替换为全局对象，而是原样传入函数。

4.3 静默失败升级为显式报错

这是严格模式提升可调试性的关键一类改动。以下操作在非严格模式下会“安静地失败”（不生效但也不报错），在严格模式下全部抛出 TypeError：

• 给不可写（writable: false）的属性赋值；
• 给只有 getter、没有 setter 的属性赋值；
• 给不可扩展对象（经 Object.preventExtensions 处理）添加新属性；
• 删除不可配置（configurable: false）的属性，例如 delete Object.prototype；
• 在原始值（数字、字符串、布尔值）上创建属性。

"use strict";
const config = {};
Object.defineProperty(config, "host", { value: "localhost", writable: false });
config.host = "example.com"; // TypeError: 无法给只读属性赋值
delete Object.prototype;     // TypeError
"abc".flag = true;           // TypeError

4.4 禁止 with 语句

with 会把一个对象的属性动态注入当前作用域，导致变量引用无法在编译期静态确定——代码里的 x 到底是局部变量、外层变量还是 with 对象的属性，必须运行到那一行才能知道。这不仅容易引发隐蔽的变量遮蔽错误，也让引擎难以进行静态优化。严格模式直接将其判定为语法错误：

"use strict";
with (obj) { x = 1; } // SyntaxError

4.5 禁止传统八进制字面量

以 0 开头的八进制字面量（如 010）容易与十进制混淆，历史遗留代码中因此产生的错误不在少数。严格模式禁止该写法；ES6 提供了显式前缀 0o 表示八进制，可以正常使用：

"use strict";
const a = 010;  // SyntaxError: 八进制字面量不被允许
const b = 0o10; // 合法，值为 8

4.6 函数与参数层面的约束

• 重名参数：非严格模式下 function f(a, a) {} 是合法的（只能取到后面那个 a），严格模式下直接报语法错误；
• callee 与 caller 被禁用：arguments.callee、arguments.caller 以及函数对象的 caller、arguments 属性均被禁止，访问时抛出 TypeError。这类特性会阻碍引擎的内联优化与栈内分析，对递归等场景也不友好；
• arguments 与命名参数解绑：非严格模式下，修改命名参数会同步反映到 arguments 对象中，严格模式下二者彼此独立：

"use strict";
function demo(a) {
  a = 99;
  return [a, arguments[0]]; // [99, 10]，互不影响
}
demo(10);

4.7 eval 的作用域隔离

严格模式下，eval 内部通过 var 声明的变量只存在于 eval 自身的作用域中，不再泄漏到外部：

"use strict";
eval("var leaked = 1;");
console.log(leaked); // ReferenceError

这显著提升了代码的静态可分析性，也是各类静态检查工具得以可靠工作的前提之一。

4.8 保留字扩充

严格模式将 implements、interface、let、package、private、protected、public、static、yield 等名称保留为关键字，不得作为标识符使用。这为后续语法演进预留了空间，也避免了新旧语义冲突——其中 let、static、yield 后来确实被正式启用。

五、工程实践建议

1. 新项目一律启用。无论通过模块化构建还是显式声明，确保代码运行在严格模式下，应成为团队代码规范的底线条款。
2. 优先使用ES模块。模块默认严格、默认作用域隔离，从源头规避全局污染与模式泄漏问题。
3. 遗留代码迁移循序渐进。可先在函数级粒度开启严格模式逐一验证，或借助静态检查工具扫描出隐式全局、with、arguments.callee 等用法，按错误清单逐条修复——常见改法包括补齐变量声明、为构造函数增加 new 调用检查、以函数名或具名函数表达式替代 arguments.callee 等。
4. 把严格模式当作免费的“错误放大器”。它把大量潜在缺陷从运行中的静默错误提前为开发期显式报错，与单元测试配合使用，可以在上线前拦截大批低级但隐蔽的问题。

六、总结

严格模式是JavaScript从“宽容解释”走向“严谨执行”的里程碑式设计：它没有破坏任何存量代码——不声明就维持旧行为；但对选择启用的开发者，它交出了一整套更可预测、更易优化、错误更早暴露的执行环境。理解其背后“将静默失败转为显式报错、将运行期隐患提前为语法期/开发期错误”的设计思路，比死记规则本身更有价值。在现代以模块为基础的开发体系中，严格模式早已是默认底色；掌握本文列举的核心规则与边界行为，能够帮助你写出更健壮、更规范、更经得起长期维护的JavaScript代码。