JavaScript 严格模式（Strict Mode）的编译器加速原理：通过静态词法约束提升隐藏类生成的稳定性

JavaScript 严格模式与引擎优化：通过静态词法约束提升隐藏类生成的稳定性

各位同仁，大家好。今天我们将深入探讨一个在现代 JavaScript 开发中至关重要，但其底层优化原理却常常被忽略的主题：JavaScript 严格模式（Strict Mode）如何通过引入静态词法约束，显著提升 JavaScript 引擎中隐藏类（Hidden Classes）生成的稳定性，进而实现编译器加速。

JavaScript 是一门动态、弱类型的语言。它的灵活性赋予了开发者极大的自由度，但也为底层引擎的优化带来了巨大挑战。为了弥合这种矛盾，现代 JavaScript 引擎（如 V8、SpiderMonkey、JavaScriptCore）投入了大量资源进行即时编译（JIT）和运行时优化。其中，隐藏类是 V8 引擎（以及其他引擎类似概念，如 SpiderMonkey 的 Shapes、JavaScriptCore 的 Structures）进行高性能对象属性访问优化的核心机制。

一、JavaScript 的动态性与优化挑战

JavaScript 代码的执行通常经历解析、编译和执行几个阶段。对于高性能的 JavaScript 引擎来说，这不仅仅是简单的解释执行。它们普遍采用 JIT 编译器，将频繁执行的 JavaScript 代码片段编译成高度优化的机器码。

考虑一个简单的对象属性访问：obj.property。在静态语言如 C++ 中，编译器在编译时就能确定 obj 的类型以及 property 在内存中的精确偏移量，从而生成直接的内存访问指令。但在 JavaScript 中，由于其动态特性，obj 的类型在运行时可能随时改变，property 甚至可能在运行时被添加或删除。

let obj = {}; // obj 是一个空对象
obj.x = 10;   // 添加属性x
obj.y = 20;   // 添加属性y

function getX(o) {
    return o.x;
}

let a = { x: 1 };
let b = { y: 2, x: 3 };
let c = { z: 4 };

getX(a); // 第一次调用
getX(b); // 第二次调用
getX(c); // 第三次调用，c没有x属性

在上述 getX 函数中，每次调用时传入的 o 对象结构可能不同。对于引擎来说，如何高效地查找 o.x 是一个核心问题。简单地遍历对象属性链或使用哈希表查找会非常慢。这就是隐藏类发挥作用的地方。

二、隐藏类（Hidden Classes）及其在V8引擎中的作用

V8 引擎引入了“隐藏类”（Hidden Classes）的概念来优化对象属性的访问。每个 JavaScript 对象都有一个与之关联的隐藏类。这个隐藏类描述了对象的结构，包括它有哪些属性，以及这些属性在内存中的偏移量。

2.1 隐藏类的生成与转换

当一个对象被创建时，它会获得一个初始的隐藏类。每当向对象添加新的属性时，V8 就会生成一个新的隐藏类，并根据旧的隐藏类和新添加的属性来创建一个转换路径。

// 1. 创建一个空对象
let obj = {};
// 此时，obj 关联着 HiddenClass_0 (空对象)
// HiddenClass_0: { }

// 2. 添加属性 'x'
obj.x = 10;
// V8 创建 HiddenClass_1，描述对象有一个属性 'x'，它在内存中的偏移量
// 并记录从 HiddenClass_0 到 HiddenClass_1 的转换路径 (通过添加 'x')
// obj 现在关联着 HiddenClass_1: { x: offset_x }

// 3. 添加属性 'y'
obj.y = 20;
// V8 创建 HiddenClass_2，描述对象有属性 'x' 和 'y'
// 并记录从 HiddenClass_1 到 HiddenClass_2 的转换路径 (通过添加 'y')
// obj 现在关联着 HiddenClass_2: { x: offset_x, y: offset_y }

如果另一个对象以相同的顺序添加相同的属性，V8 会复用已经存在的隐藏类和转换路径，而不是创建新的。

let objA = {};
objA.x = 1;
objA.y = 2;
// objA 遵循 HiddenClass_0 -> HiddenClass_1 -> HiddenClass_2 的路径

let objB = {};
objB.x = 3;
objB.y = 4;
// objB 也遵循 HiddenClass_0 -> HiddenClass_1 -> HiddenClass_2 的路径
// 它们共享相同的隐藏类结构，只是存储的值不同。

2.2 内联缓存（Inline Caching, IC）与隐藏类

隐藏类与内联缓存（IC）紧密配合，实现了属性访问的加速。当引擎第一次执行 obj.property 这样的代码时，它会查找 obj 的隐藏类，找到 property 的偏移量，然后缓存这个结果。

• Monomorphic（单态）: 如果后续对 obj.property 的访问，obj 始终具有相同的隐藏类，IC 就可以直接使用缓存的偏移量，直接从内存中读取属性值，速度非常快。这是最高效的情况。
• Polymorphic（多态）: 如果 obj 的隐藏类在几次调用中有所不同（但数量不多），IC 会缓存多个隐藏类及其对应的偏移量。每次访问时，它会检查当前 obj 的隐藏类是否在缓存中，如果在，则使用对应的偏移量。这比单态慢，但仍比完全动态查找快。
• Megamorphic（巨多态）: 如果 obj 的隐藏类变化过于频繁或数量过多，IC 会放弃缓存具体的隐藏类信息，转而回退到更通用的、更慢的查找机制（例如哈希表查找）。这会导致性能显著下降，通常被称为“去优化”（Deoptimization）。

function accessProperty(obj) {
    return obj.a;
}

// 第一次调用，obj1: { a: 1 } -> HiddenClass_A
let obj1 = { a: 1 };
accessProperty(obj1); // IC 缓存 HiddenClass_A -> offset_a

// 第二次调用，obj2: { a: 2 } -> HiddenClass_A (相同隐藏类)
let obj2 = { a: 2 };
accessProperty(obj2); // IC 命中，直接使用 offset_a

// 第三次调用，obj3: { b: 1, a: 3 } -> HiddenClass_B (不同隐藏类，但属性a存在)
let obj3 = { b: 1, a: 3 };
accessProperty(obj3); // IC 变为多态，缓存 HiddenClass_B -> offset_a

// 第四次调用，obj4: { c: 1, d: 2, a: 4 } -> HiddenClass_C (又一个不同的隐藏类)
let obj4 = { c: 1, d: 2, a: 4 };
accessProperty(obj4); // IC 仍然是多态，缓存 HiddenClass_C -> offset_a

// 假设我们有几十种不同形状但都有属性 'a' 的对象...
// 最终 IC 可能变为巨多态，导致性能下降。

2.3 影响隐藏类稳定性的因素

以下行为会破坏隐藏类的稳定性，导致引擎难以进行单态优化：

• 在运行时动态添加或删除属性： 这是最常见的，比如 obj.newProp = value; 或 delete obj.existingProp;。
• 使用 delete 操作符： delete 属性会强制引擎创建新的隐藏类，因为这改变了对象的结构。
• 使用 eval()： eval() 可以在运行时改变作用域，甚至引入新的变量，使静态分析变得不可能。
• 使用 with 语句： with 语句会动态地改变作用域链，使得属性查找变得极其不确定，引擎无法在编译时确定属性的来源。
• 访问 arguments.caller 或 arguments.callee： 这些属性提供对调用栈的动态访问，阻止了某些优化，如函数内联。
• 不同对象的属性初始化顺序不同： 即使是相同的属性，如果初始化顺序不同，也会导致不同的隐藏类。

let o1 = {};
o1.x = 1;
o1.y = 2; // HiddenClass_A

let o2 = {};
o2.y = 1;
o2.x = 2; // HiddenClass_B (不同于 HiddenClass_A)

可以看出，JavaScript 的动态性是其强大的源泉，但同时也给引擎优化带来了显著的挑战。这就是严格模式登场的原因。

三、JavaScript 严格模式：引入静态词法约束

JavaScript 严格模式（Strict Mode）是 ECMAScript 5 引入的一种新的 JavaScript 执行模式。它旨在通过消除 JavaScript 语言中一些不安全、容易出错或难以优化的特性，提供更严格的错误检查和更清晰的语义。它的主要目标包括：

1. 消除静默错误： 将一些过去会静默失败或行为不确定的操作，转变为抛出错误。
2. 纠正 JavaScript 引擎难以优化的错误： 移除一些阻止引擎进行高效优化的特性。
3. 禁用不安全的特性： 废弃一些被认为是设计缺陷或容易引入安全漏洞的语法。
4. 为未来的 ECMAScript 版本做准备： 引入一些在未来版本中可能成为默认行为的新规则。

3.1 如何启用严格模式

严格模式可以在脚本文件的开头或函数内部启用：

• 全局严格模式：

  "use strict";
  // 整个脚本都将以严格模式运行
  function doSomething() {
      // ...
  }

• 函数严格模式：

  function doSomethingStrict() {
      "use strict";
      // 只有这个函数内部的代码以严格模式运行
      // 外面的代码仍然是非严格模式
  }

当整个脚本或模块（ES Module 默认就是严格模式）以严格模式运行时，所有代码都受到严格模式的约束。

3.2 严格模式的主要约束

严格模式引入了诸多限制，这些限制并非仅仅为了“让代码更安全”，它们更是为了“让代码更可预测”，从而为引擎的优化提供更多静态信息。以下是一些关键约束：

约束类型	非严格模式行为	严格模式行为	优化影响
语法错误
with 语句	允许使用，动态改变作用域链	语法错误（SyntaxError）	消除不确定性，允许引擎在编译时确定变量查找路径。
隐式创建全局变量	未声明的变量赋值自动创建全局变量	抛出 ReferenceError	避免意外的全局对象属性添加，保持全局对象隐藏类稳定。
eval 变量声明	eval("var x;") 在当前作用域创建 x	eval("var x;") 只在 eval 自己的作用域创建 x	限制 eval 的副作用，使其更易于优化或完全避免优化障碍。
重复的参数名	允许，后者覆盖前者	语法错误（SyntaxError）	确保函数签名明确，简化 arguments 对象的结构。
arguments.caller/callee	允许访问，提供对调用栈的动态引用	抛出 TypeError	消除对调用栈的动态依赖，允许函数内联等优化。
八进制字面量	允许使用 010 表示八进制数	语法错误（SyntaxError）	消除语言歧义，简化解析器。
delete 变量	允许 delete 变量名，但无效且返回 false	语法错误（SyntaxError）	确保变量的生命周期和作用域在编译时是明确的。
implements, interface, let, package, private, protected, public, static, yield 作为标识符	允许使用（除非是保留字）	语法错误（SyntaxError）	为未来语言特性保留关键词，避免潜在冲突。
运行时错误
删除不可配置属性	静默失败，返回 false	抛出 TypeError	强制显式错误，避免对象结构意外改变，保持隐藏类稳定性。
对象字面量中的重复属性名	允许，后者覆盖前者（ES5 非严格）	语法错误（SyntaxError）（ES5 严格）	确保对象初始形状的唯一性（ES6+ 无论严格与否都允许，但行为一致）。
对只读属性赋值	静默失败，不抛出错误	抛出 TypeError	强制显式错误，避免对象属性值意外修改，保持隐藏类稳定性。
对不可扩展对象添加属性	静默失败，不抛出错误	抛出 TypeError	强制显式错误，避免对象结构意外改变，保持隐藏类稳定性。
函数中 this 的值	非方法调用时，this 默认绑定到全局对象（window/global）	非方法调用时，this 为 undefined	避免意外修改或创建全局对象的属性，保持全局对象隐藏类稳定性。

四、核心原理：严格模式的静态词法约束与隐藏类稳定性

现在我们深入探讨，严格模式的这些约束是如何直接或间接提升隐藏类生成的稳定性，进而加速编译器的。

4.1 消除 with 语句：移除作用域查找的黑洞

with 语句是 JavaScript 中一个臭名昭著的特性，它允许你将一个对象的属性添加到当前作用域链的顶端。

// 非严格模式
let obj = { x: 10, y: 20 };
let z = 30;

with (obj) {
    console.log(x); // 10 (来自 obj)
    console.log(y); // 20 (来自 obj)
    console.log(z); // 30 (来自外部作用域)
    foo = 40;       // 意外创建全局变量 foo (如果 obj 中没有 foo)
}
console.log(foo); // 40

with 语句的问题在于，它使得变量的查找路径在编译时无法确定。当引擎遇到 with (obj) { ... } 中的一个变量（例如 x）时，它不知道 x 是 obj.x 还是外部作用域中的 x，或者甚至是一个隐式创建的全局变量。这种不确定性迫使引擎：

• 无法进行静态分析： 编译器无法预知 obj 的具体结构，也无法确定 x 在内存中的位置。
• 无法利用隐藏类： 属性访问 x 的目标（是 obj 还是外部作用域）是动态的，这意味着引擎无法为 x 的查找生成单态或多态的内联缓存。它必须回退到最慢的、基于运行时查找的机制。
• 阻止函数内联： 包含 with 语句的函数通常无法被 JIT 编译器内联到调用者中，因为其作用域行为过于复杂。

严格模式直接将 with 语句声明为语法错误。 这一禁令移除了 JavaScript 语言中最大的动态作用域不确定性来源。一旦 with 语句被禁止，编译器就可以在编译时更可靠地分析变量的词法作用域，从而：

• 稳定隐藏类： 由于不再存在 with 语句可能引入的动态属性查找，对象的属性访问模式变得更加可预测。引擎可以更自信地生成和复用隐藏类，并创建单态的内联缓存。
• 实现更积极的优化： 编译器可以进行更积极的函数内联、死代码消除等优化，因为作用域链在编译时是确定的。

4.2 限制 eval() 的作用域：减少运行时代码修改的冲击

eval() 函数允许在运行时执行任意字符串作为 JavaScript 代码。这使得 eval() 内部的代码可以访问和修改当前作用域，甚至引入新的变量。

// 非严格模式
function nonStrictModeEval() {
    var x = 10;
    eval("var y = 20; x = 30;");
    console.log(x); // 30
    console.log(y); // 20
}
nonStrictModeEval();

eval() 的问题在于，它可能在运行时改变当前作用域，使得静态分析变得极其困难。就像 with 语句一样，引擎无法在编译时确定 eval() 是否会引入新的变量，或者修改现有变量的值。这会：

• 阻止作用域优化： 引擎无法确定变量的生命周期和作用域。
• 影响隐藏类： 如果 eval() 修改了对象的属性，或者创建了新的全局属性，它将直接影响相关对象的隐藏类稳定性。

严格模式下，eval() 的行为被限制： 它不再能够在其外部作用域中声明变量或修改外部作用域的变量。它执行的代码拥有一个独立的作用域。

// 严格模式
function strictModeEval() {
    "use strict";
    var x = 10;
    eval("var y = 20; x = 30;"); // 试图修改x会失败或在独立作用域中创建新的x
    console.log(x); // 10 (x 未被修改)
    // console.log(y); // ReferenceError: y is not defined (y 在eval的独立作用域中)
}
strictModeEval();

通过限制 eval() 的作用域，严格模式减少了运行时代码对外部作用域和对象结构的不可预测影响。这使得引擎：

• 更容易进行作用域分析： 即使有 eval()，引擎也能更清晰地知道哪些变量是静态确定的，哪些是 eval 内部的。
• 减少对隐藏类的干扰： eval 导致的外部作用域或全局对象属性的意外修改被大大限制，从而维护了这些对象隐藏类的稳定性。

4.3 禁用隐式全局变量：保护全局对象隐藏类

在非严格模式下，如果一个变量未经声明就被赋值，它会自动成为全局对象的属性。

// 非严格模式
function assignGlobal() {
    myGlobalVar = 100; // 自动成为全局对象的属性
}
assignGlobal();
console.log(window.myGlobalVar); // 100 (在浏览器环境中)

这种行为会导致：

• 全局对象污染： 意外地在全局对象上创建了属性，这可能导致命名冲突。
• 全局对象隐藏类的不稳定： 全局对象（window 或 global）是一个非常特殊的、经常被访问的对象。如果函数可以在运行时随意向其添加属性，那么全局对象的隐藏类将频繁发生转换，导致对全局对象属性访问的去优化。

严格模式下，对未声明变量赋值会抛出 ReferenceError。

// 严格模式
function assignGlobalStrict() {
    "use strict";
    // myGlobalVar = 100; // ReferenceError: myGlobalVar is not defined
}
assignGlobalStrict();

这一约束强制开发者显式声明所有变量（var、let、const），从而：

• 保护全局对象： 避免了意外的全局对象属性创建。
• 稳定全局对象的隐藏类： 全局对象的隐藏类结构在程序运行时变得更加稳定，因为它的属性不再能被随意添加。这允许引擎为全局对象的属性访问生成高效的内联缓存。

4.4 禁止删除不可配置属性：维护对象结构的稳定性

在非严格模式下，尝试删除一个不可配置（non-configurable）的属性会静默失败，并返回 false。

// 非严格模式
let obj = {};
Object.defineProperty(obj, 'x', { configurable: false, value: 10 });
console.log(delete obj.x); // false
console.log(obj.x);        // 10 (属性仍在)

虽然它返回 false 表明删除失败，但代码执行并不会中断，这可能掩盖了逻辑错误。更重要的是，在严格模式下，这种行为被视为一个错误。

严格模式下，删除不可配置属性会抛出 TypeError。

// 严格模式
let objStrict = {};
Object.defineProperty(objStrict, 'x', { configurable: false, value: 10 });
// delete objStrict.x; // TypeError: Cannot delete property 'x' of #<Object>

这一约束确保了：

• 明确的错误提示： 开发者可以立即发现并修复删除不可配置属性的尝试。
• 隐藏类的稳定性： 尽管 delete 操作本身通常会触发新的隐藏类生成，但严格模式通过抛出错误，阻止了对不应该被删除的属性的删除操作，从而避免了可能导致隐藏类不必要的转换或混乱的场景。它强制了对象结构的明确性。

4.5 禁用 arguments.caller 和 arguments.callee：允许函数内联

arguments.caller 和 arguments.callee 属性允许在函数内部动态地访问调用当前函数的函数以及当前函数本身。

// 非严格模式
function outer() {
    function inner() {
        console.log(inner.caller === outer); // true
        console.log(arguments.callee === inner); // true
    }
    inner();
}
outer();

这些属性的问题在于：

• 阻止内联优化： 当一个函数（例如 inner）访问 arguments.caller 或 arguments.callee 时，引擎无法安全地将 inner 函数内联到 outer 函数中。内联是一种强大的优化，它将一个函数的代码直接嵌入到调用它的地方，消除函数调用的开销。如果 inner 依赖于其在调用栈中的位置（通过 caller），内联就会改变这个位置，从而破坏其语义。
• 复杂的调用栈管理： 引擎需要维护更复杂的调用栈信息，以确保这些动态属性的正确性，这增加了运行时开销。

严格模式下，访问 arguments.caller 或 arguments.callee 会抛出 TypeError。

// 严格模式
function outerStrict() {
    "use strict";
    function innerStrict() {
        // console.log(arguments.caller); // TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to strict mode functions.
    }
    innerStrict();
}
outerStrict();

通过禁用这些属性，严格模式移除了函数在运行时对其调用上下文的动态依赖。这使得 JIT 编译器能够：

• 更积极地进行函数内联： 引擎可以安全地将严格模式下的短函数内联到其调用者中，从而显著减少函数调用的开销，提高整体执行速度。
• 简化调用栈管理： 引擎不再需要为这些动态属性维护额外的元数据，从而进一步提升性能。

4.6 限制 this 的绑定：避免意外的全局对象操作

在非严格模式下，如果一个函数作为普通函数调用（而不是作为对象的方法），其内部的 this 会被默认绑定到全局对象（在浏览器中是 window，在 Node.js 中是 global）。

// 非严格模式
function logThis() {
    console.log(this === window); // true (在浏览器中)
    this.newProp = "hello";      // 意外地在全局对象上创建属性
}
logThis();
console.log(window.newProp); // "hello"

这种默认绑定到全局对象的行为，可能导致：

• 意外的全局对象污染： 函数内部的 this 意外地在全局对象上创建或修改属性。
• 全局对象隐藏类的不稳定： 类似于隐式全局变量，这种行为会频繁改变全局对象的隐藏类，导致对全局对象属性访问的去优化。

严格模式下，当函数作为普通函数调用时，其内部的 this 会是 undefined。

// 严格模式
function logThisStrict() {
    "use strict";
    console.log(this === undefined); // true
    // this.newProp = "hello"; // TypeError: Cannot set properties of undefined (setting 'newProp')
}
logThisStrict();

通过将 this 绑定为 undefined，严格模式强制开发者更显式地管理 this 的上下文。这直接有助于：

• 保护全局对象隐藏类： 阻止了通过 this 意外向全局对象添加属性，从而维护了全局对象的隐藏类稳定性。
• 更清晰的语义： 开发者能够更清楚地知道 this 的值，减少了由于隐式绑定而导致的错误。

4.7 对象字面量中的重复属性名（ES5 严格模式）和对不可扩展对象添加属性

• ES5 严格模式下，对象字面量中不允许出现重复属性名。

  // ES5 严格模式
  // "use strict";
  // var o = { p: 1, p: 2 }; // SyntaxError

  虽然现代 JavaScript 引擎（ES6+）无论是否严格模式都允许重复属性名（且最后一个属性会覆盖前面的），但 ES5 严格模式的这一约束在当时确保了对象初始隐藏类的唯一性和可预测性。如果允许重复，引擎需要额外逻辑来处理这种歧义，可能影响隐藏类生成。

• 对不可扩展对象添加属性：

  // 严格模式
  "use strict";
  let obj = {};
  Object.preventExtensions(obj);
  // obj.newProp = 10; // TypeError: Cannot add property newProp, object is not extensible

  在非严格模式下，尝试向不可扩展对象添加属性会静默失败。严格模式下则会抛出 TypeError。这确保了对象一旦被标记为不可扩展，其结构就不能再被修改，从而维护了该对象隐藏类的最终稳定性。引擎可以确信该对象的形状不会再变，从而进行更激进的优化。

五、编译器加速的机制

综合来看，严格模式通过引入静态词法约束，为 JavaScript 引擎的 JIT 编译器提供了更强的保证和更清晰的信号。这些约束共同作用，使得编译器能够：

1. 更早地进行类型推断： 由于消除了许多动态行为（如 with、eval 对作用域的修改、隐式全局变量），引擎在解析和编译阶段就能对变量和对象的结构做出更准确的预测。
2. 生成更稳定的隐藏类：
   • 限制了在运行时动态添加或删除属性（如通过隐式全局变量、this 绑定）。
   • 强制了对象结构的明确性（如禁止删除不可配置属性、对不可扩展对象添加属性抛错）。
   • 避免了 delete 操作对变量的不可预测影响。
     这些都使得对象的隐藏类在程序生命周期中更少地发生转换，或者转换路径更短、更可预测。
3. 提高内联缓存的命中率和单态性： 隐藏类的稳定性直接导致了内联缓存（IC）在运行时更有可能保持单态或多态，而不是回退到巨多态。单态 IC 是最快的属性访问方式，因为它只需一次查找即可命中缓存的偏移量。
4. 进行更积极的优化：
   • 函数内联： 禁用 arguments.caller/callee 移除了函数内联的障碍。
   • 死代码消除： 明确的作用域和变量声明有助于编译器识别和移除无用的代码。
   • 寄存器分配： 稳定的类型信息和可预测的内存布局使得编译器能够更好地分配寄存器，减少内存访问。
5. 减少去优化： 由于运行时类型和结构的变化减少，引擎发现其编译时假设被打破的情况更少，从而减少了将优化后的机器码回退到未优化或更通用代码的频率。去优化是一个昂贵的过程，减少它可以显著提升性能。

下表总结了严格模式对引擎优化的主要贡献：

严格模式特性	对隐藏类/优化影响
禁用 with 语句	消除动态作用域查找，使变量查找路径在编译时确定，允许单态 IC 和更激进的函数内联。
限制 eval() 作用域	减少运行时代码对外部作用域和对象结构的修改，保护外部作用域和全局对象的隐藏类稳定性。
禁用隐式全局变量	防止意外的全局对象属性添加，极大地稳定了全局对象的隐藏类，提升全局属性访问速度。
delete 变量抛错	确保变量的生命周期明确，有助于编译器静态分析。
删除不可配置属性抛错	强制对象结构的明确性，避免意外修改，维护隐藏类稳定性。
禁用 arguments.caller/callee	消除函数对调用栈的动态依赖，允许 JIT 编译器进行关键的函数内联优化。
限制 this 绑定	避免 this 意外指向全局对象并添加属性，稳定全局对象的隐藏类。
对不可扩展对象添加属性抛错	保证对象一旦被标记为不可扩展，其结构不再改变，使引擎能够对这些对象进行更激进的优化。

六、结论

严格模式不仅仅是一种“更好”的编程实践，它更是现代 JavaScript 引擎实现高性能的关键基石。通过引入一系列静态词法约束，严格模式消除了 JavaScript 语言中许多导致运行时行为不确定性的“陷阱”。这些确定性使得 JIT 编译器能够进行更深入的静态分析，生成更稳定、更可预测的隐藏类，从而极大地提升内联缓存的效率，减少去优化，并开启更积极的编译优化。因此，拥抱严格模式不仅能写出更健壮、更易于维护的代码，更是在直接为应用程序的运行时性能贡献力量。