JavaScript 严格模式（Strict Mode）：对 V8 优化与代码行为的规范化影响

最新推荐文章于 2025-12-13 18:06:01 发布

原创最新推荐文章于 2025-12-13 18:06:01 发布 · 732 阅读

11 ·

CC 4.0 BY-SA版权

文章标签：

#javascript #开发语言 #ecmascript #Javascript

尊敬的各位开发者、技术爱好者们，大家好！

今天，我们将深入探讨一个在JavaScript发展历程中具有里程碑意义的特性：严格模式（Strict Mode）。它不仅仅是一个语法开关，更是JavaScript语言设计哲学的一次重要演进，对V8等现代JavaScript引擎的优化能力以及我们日常编写的代码行为产生了深远的影响。作为一名编程专家，我希望通过这次讲座，带领大家全面理解严格模式的来龙去脉、核心规则，以及它如何成为构建高性能、可维护JavaScript应用的基础。

引言：混沌与秩序的抉择

在ECMAScript 5（ES5）发布之前，JavaScript被认为是一种“宽容”的语言。这种宽容性固然降低了新手的学习门槛，但也埋下了许多陷阱：默默失败的操作、意外的全局变量、难以预测的this绑定，以及一些被视为“坏习惯”的语言特性。这些问题不仅导致了难以调试的bug，也给JavaScript引擎的优化带来了巨大的挑战。

想象一下，一个优化器在面对一个可能随时通过eval改变作用域、或者通过隐式全局变量污染环境的代码时，它需要进行多少保守的假设和防御性编程？这些假设和防御性措施，无一例外地会阻碍更激进的优化。

严格模式正是为了解决这些问题而生。它旨在提供一个更安全、更清晰、更可预测的JavaScript子集。通过强制执行一套更严格的规则，它将许多静默失败的操作转变为抛出错误，消除了语言中一些不安全的特性，并为未来的语言特性预留了空间。对于V8这类追求极致性能的JavaScript引擎而言，严格模式所带来的“秩序”，是其进行深度优化的基石。

启用严格模式：两种方式

启用严格模式非常简单，可以在脚本的顶部或函数的内部声明：

全局严格模式： 将"use strict";放在脚本文件的最顶部。
```
"use strict";

// 整个脚本都处于严格模式下
function globalStrictFunction() {
    // ...
}

// ...
```
注意： 当拼接多个文件时，如果其中一个文件是严格模式，可能会影响到其他非严格模式的文件。因此，通常建议在模块化开发中（如ES Modules）使用函数级别的严格模式，或者利用现代构建工具确保每个文件都有正确的上下文。不过，ES Modules本身就默认处于严格模式，无需显式声明。
函数级别严格模式： 将"use strict";放在函数体的最顶部。
```
// 这个脚本本身不是严格模式
let globalVar = 10;

function nonStrictFunction() {
    // ...
}

function strictFunction() {
    "use strict"; // 只有这个函数内部的代码处于严格模式
    // ...
}
```
这种方式允许在同一个文件中混合使用严格模式和非严格模式的代码，提供了更大的灵活性，尤其是在逐步迁移旧代码库时非常有用。

一旦启用，严格模式将作用于其声明的整个上下文（整个脚本或整个函数），并且是不可撤销的。

严格模式对代码行为的规范化影响

严格模式通过引入一系列新的规则，显著改变了JavaScript代码的行为。这些改变主要是为了：

将静默失败转换为抛出错误： 捕获开发者常见的错误，提高代码健壮性。
消除不安全的特性： 移除或限制那些可能导致意外行为或难以优化的语言特性。
简化未来发展： 为ECMAScript的后续版本引入新特性铺平道路。

接下来，我们将详细探讨这些行为上的规范化。

1. 禁止隐式创建全局变量

在非严格模式下，如果一个变量在没有声明（var、let、const）的情况下被赋值，它会自动成为全局对象（浏览器中的window，Node.js中的global）的属性。这是一种常见的错误源，因为开发者可能无意中污染了全局命名空间。

非严格模式：

function createImplicitGlobal() {
    // x 在这里没有通过 var/let/const 声明
    x = 10;
}
createImplicitGlobal();
console.log(x); // 输出: 10 (全局变量)

严格模式：

"use strict";
function createImplicitGlobalStrict() {
    // 尝试创建隐式全局变量
    y = 20; // 这里的 y 没有声明
}
try {
    createImplicitGlobalStrict();
} catch (e) {
    console.error(e.message); // 输出: y is not defined (ReferenceError)
}
// console.log(y); // 这里会再次抛出 ReferenceError，因为 y 未定义

在严格模式下，y = 20; 会抛出一个 ReferenceError，强制开发者显式声明所有变量，从而避免了意外的全局变量污染。这对于维护代码的清晰性和避免命名冲突至关重要。

2. 禁止删除普通变量、函数名或参数

在非严格模式下，可以尝试删除变量，但通常不会成功（delete操作符主要用于删除对象的属性）。然而，在严格模式下，尝试删除一个不可配置的属性（例如，通过var声明的变量、函数声明的函数名、函数参数）会直接抛出错误。

非严格模式：

let a = 1;
delete a; // 返回 false，但不会抛出错误
console.log(a); // 输出: 1

function f() {}
delete f; // 返回 false
console.log(f); // 输出: [Function: f]

严格模式：

"use strict";
let b = 1;
try {
    delete b; // 抛出 TypeError
} catch (e) {
    console.error(e.message); // 输出: Delete of an unqualified identifier in strict mode.
}

function g(param) {
    delete param; // 抛出 TypeError
}
try {
    g(10);
} catch (e) {
    console.error(e.message); // 输出: Delete of an unqualified identifier in strict mode.
}

这项规则强制了变量和函数声明的生命周期管理，使其更加明确。

3. `this`值的变化

在非严格模式下，当一个函数以非方法形式（即不作为对象的方法）被调用时，其内部的this会被自动绑定到全局对象（浏览器中的window，Node.js中的global）。这被称为this的“全局对象绑定回退”。对于构造函数，如果忘记使用new，this也会绑定到全局对象。

非严格模式：

function showThisNonStrict() {
    console.log(this === window); // 浏览器环境中为 true (Node.js中为 global)
}
showThisNonStrict(); // 独立调用

const objNonStrict = {
    method: function() {
        // 在方法中，this 绑定到 objNonStrict
        console.log(this === objNonStrict); // true
        // 但如果方法内部的嵌套函数是独立调用，this 依然会回退到全局对象
        (function() {
            console.log("Nested non-strict this:", this === window); // true
        })();
    }
};
objNonStrict.method();

严格模式：

"use strict";
function showThisStrict() {
    console.log(this); // 输出: undefined
}
showThisStrict(); // 独立调用

const objStrict = {
    method: function() {
        console.log(this === objStrict); // true
        // 严格模式下的嵌套函数，如果独立调用，this 仍然是 undefined
        (function() {
            console.log("Nested strict this:", this); // 输出: undefined
        })();
    }
};
objStrict.method();

// 使用 call/apply/bind 明确指定 this 则不受影响
function greet(name) {
    "use strict";
    console.log(`Hello, ${name} from ${this ? this.location : 'unknown location'}`);
}
greet.call({ location: 'New York' }, 'Alice'); // 输出: Hello, Alice from New York
greet('Bob'); // 输出: Hello, Bob from unknown location (this is undefined)

在严格模式下，当函数以非方法形式调用时，this的值将是undefined，而不是全局对象。这消除了this的隐式全局绑定回退，使得this的行为更加可预测，避免了意外的全局污染，并鼓励开发者显式地管理this的上下文。

4. 禁止重复的参数名

在非严格模式下，函数可以定义具有相同名称的参数，虽然这通常是无意义的，因为只有最后一个同名参数有效。

非严格模式：

function sumNonStrict(a, b, a) {
    console.log(a, b); // 输出: 3 2 (最后一个 a 的值)
    return a + b;
}
sumNonStrict(1, 2, 3);

严格模式：

"use strict";
function sumStrict(a, b, a) { // 抛出 SyntaxError
    // ...
}
try {
    // 尝试定义这样的函数会立即抛出错误，不会等到调用时
} catch (e) {
    console.error(e.message); // 输出: Duplicate parameter name not allowed in strict mode
}

严格模式禁止在函数中使用重复的参数名，这消除了语法上的歧义和潜在的错误。

5. `arguments`对象的限制

arguments对象在非严格模式下有一些特性，在严格模式下被修改或禁止。

5.1 `arguments`和参数的解耦

在非严格模式下，arguments对象中的元素与函数参数之间是“双向绑定”的。改变arguments[i]会同时改变对应的参数，反之亦然。

非严格模式：

function updateArgsNonStrict(a, b) {
    console.log(`Before: a=${a}, b=${b}, arguments[0]=${arguments[0]}, arguments[1]=${arguments[1]}`);
    a = 10;
    arguments[1] = 20;
    console.log(`After: a=${a}, b=${b}, arguments[0]=${arguments[0]}, arguments[1]=${arguments[1]}`);
}
updateArgsNonStrict(1, 2);
// 输出:
// Before: a=1, b=2, arguments[0]=1, arguments[1]=2
// After: a=10, b=20, arguments[0]=10, arguments[1]=20

这种行为增加了复杂性，并阻碍了引擎对参数和arguments对象的优化。

严格模式：

"use strict";
function updateArgsStrict(a, b) {
    console.log(`Before: a=${a}, b=${b}, arguments[0]=${arguments[0]}, arguments[1]=${arguments[1]}`);
    a = 10; // 改变 a
    arguments[1] = 20; // 改变 arguments[1]
    console.log(`After: a=${a}, b=${b}, arguments[0]=${arguments[0]}, arguments[1]=${arguments[1]}`);
}
updateArgsStrict(1, 2);
// 输出:
// Before: a=1, b=2, arguments[0]=1, arguments[1]=2
// After: a=10, b=20, arguments[0]=1, arguments[1]=20

在严格模式下，arguments对象是参数的静态副本。修改参数不会影响arguments对象，反之亦然。这使得参数的行为更像普通的局部变量，简化了引擎的优化。

5.2 禁止使用 `arguments.caller` 和 `arguments.callee`

在非严格模式下，arguments.callee指向当前正在执行的函数，arguments.caller指向调用当前函数的函数。这些属性在调试和某些高级递归模式中可能有用，但它们严重阻碍了引擎的优化，因为它们需要保留堆栈信息，使得函数内联和尾调用优化变得困难甚至不可能。

非严格模式：

function outer() {
    function inner() {
        console.log(inner === arguments.callee);    // true
        console.log(outer === inner.caller);        // true (arguments.caller 在 ES5 严格模式中被移除, 但在非严格模式下依然可用)
    }
    inner();
}
outer();

严格模式：

"use strict";
function outerStrict() {
    function innerStrict() {
        try {
            console.log(arguments.callee); // 抛出 TypeError
        } catch (e) {
            console.error(e.message); // 输出: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments object for strict mode functions.
        }
        try {
            console.log(innerStrict.caller); // 严格模式下，函数的 caller 属性也被禁用
        } catch (e) {
            console.error(e.message); // 相同错误
        }
    }
    innerStrict();
}
outerStrict();

在严格模式下，访问arguments.callee或arguments.caller会抛出TypeError。同样，直接访问函数对象的caller和arguments属性也会被禁止。这为V8等引擎进行更激进的优化（如内联和尾调用优化）扫清了障碍。

6. `eval`行为的改变

在非严格模式下，eval可以在其调用者的作用域中创建新的变量和函数。这使得静态分析几乎不可能，因为任何eval调用都可能改变当前作用域的结构。

非严格模式：

function nonStrictEval() {
    let x = 10;
    eval("var y = 20; console.log(x + y);"); // eval 访问并修改了 nonStrictEval 的作用域
    console.log(y); // 输出: 20
}
nonStrictEval();

严格模式：

"use strict";
function strictEval() {
    let x = 10;
    eval("var z = 30; console.log(x + z);"); // eval 在自己的独立作用域中运行
    // console.log(z); // 抛出 ReferenceError，因为 z 不在 strictEval 的作用域中
}
try {
    strictEval(); // eval 内部会输出 40
} catch (e) {
    console.error(e.message); // 尝试访问 z 会抛出 ReferenceError
}

在严格模式下，eval执行的代码会拥有一个独立的作用域，它不能在当前作用域中创建新的变量或函数。这意味着eval只能影响它自己的局部环境，不会意外地修改外部作用域。这极大地提高了代码的可预测性，并允许引擎对eval外部的代码进行更有效的优化。

7. 禁止使用八进制字面量

在非严格模式下，以0开头的数字被解释为八进制数（例如010是十进制的8）。这种行为在现代JavaScript中已不再推荐，因为它容易引起混淆，例如08或09在非严格模式下会直接被解析为8或9，而不是八进制数。

非严格模式：

console.log(010); // 输出: 8
console.log(08);  // 输出: 8 (直接忽略 0)

严格模式：

"use strict";
// console.log(010); // 抛出 SyntaxError: Octal literals are not allowed in strict mode.
// console.log(0o10); // ES6 允许使用 0o 前缀的八进制，这是一个不同的语法，在严格模式下是允许的。

严格模式禁止使用传统的八进制字面量（即以0开头的数字）。如果需要使用八进制，ES6引入了0o前缀的语法（例如0o10），这种语法在严格模式下是允许的，因为它更明确。这项规则消除了一个常见的混淆源，并简化了解析器的工作。

8. `with`语句被禁用

with语句在非严格模式下可以用来扩展作用域链，使得访问对象属性无需重复引用对象。然而，它会使代码的静态分析变得异常困难，因为在with块内部，一个变量是来自with对象还是外部作用域，只能在运行时确定。

非严格模式：

const user = { name: "Alice", age: 30 };
with (user) {
    console.log(name); // 输出: Alice
    console.log(age);  // 输出: 30
}

严格模式：

"use strict";
// const user = { name: "Alice", age: 30 };
// with (user) { // 抛出 SyntaxError
//     // ...
// }

严格模式直接禁止使用with语句，因为它极大地阻碍了JavaScript引擎进行有效的优化。移除with语句使得代码的作用域在编译时就能确定，从而极大地简化了引擎的优化任务。

9. 对只读属性、不可扩展对象和不可配置属性的修改尝试

在非严格模式下，尝试对只读属性（如Object.defineProperty定义的writable: false的属性）进行赋值，或者对不可扩展对象（Object.preventExtensions）添加新属性，或者删除不可配置的属性，这些操作通常会静默失败。

非严格模式：

const obj = {};
Object.defineProperty(obj, 'x', { value: 10, writable: false });
obj.x = 20; // 静默失败，不会改变 x 的值
console.log(obj.x); // 输出: 10

Object.preventExtensions(obj);
obj.y = 30; // 静默失败，不会添加 y 属性
console.log(obj.y); // 输出: undefined

严格模式：

"use strict";
const objStrict = {};
Object.defineProperty(objStrict, 'x', { value: 10, writable: false });
try {
    objStrict.x = 20; // 抛出 TypeError
} catch (e) {
    console.error(e.message); // 输出: Cannot assign to read only property 'x' of object '#<Object>'
}

Object.preventExtensions(objStrict);
try {
    objStrict.y = 30; // 抛出 TypeError
} catch (e) {
    console.error(e.message); // 输出: Cannot add property y, object is not extensible
}

在严格模式下，这些操作会抛出TypeError。这使得这些潜在的错误更早地暴露出来，提高了代码的健壮性。

10. 未来保留字

严格模式将一些单词（如implements、interface、let、package、private、protected、public、static、yield）列为未来保留字。在非严格模式下，这些词可以用作标识符（变量名、函数名），但在严格模式下，使用它们会抛出SyntaxError。

这项规则为ECMAScript的未来版本引入新的关键字和语法特性留下了空间，避免了与现有代码的冲突。

以下表格总结了严格模式对代码行为的主要规范化影响：

行为	非严格模式	严格模式
隐式全局变量	允许，意外创建全局对象属性	禁用，抛出 `ReferenceError`
删除普通变量/函数	静默失败（返回 `false`）	禁用，抛出 `TypeError`
`this`绑定	函数独立调用时，`this`绑定到全局对象	函数独立调用时，`this`为 `undefined`
重复参数名	允许，但只有最后一个有效	禁用，抛出 `SyntaxError`
`arguments`与参数绑定	双向绑定，修改一个影响另一个	解耦，互不影响
`arguments.callee`	允许访问，指向当前函数	禁用，抛出 `TypeError`
`arguments.caller`	允许访问，指向调用函数	禁用，抛出 `TypeError`
`eval`行为	可在其调用者作用域创建变量	在独立作用域中运行，不影响外部作用域
八进制字面量	允许（如 `010`），易混淆	禁用（如 `010`），抛出 `SyntaxError`（ES6 `0o` 允许）
`with`语句	允许，但影响作用域链	禁用，抛出 `SyntaxError`
修改只读/不可扩展属性	静默失败	禁用，抛出 `TypeError`
未来保留字	可用作标识符	禁用，抛出 `SyntaxError`

严格模式对 V8 优化的深远影响

理解了严格模式对代码行为的规范化之后，我们才能真正领会它对V8这类高性能JavaScript引擎的优化能力所带来的巨大推动作用。V8引擎的核心目标是尽可能地将JavaScript代码编译成高效的机器码，而严格模式通过消除语言的模糊性和不确定性，为V8提供了进行更激进优化的“安全区”。

1. 消除隐式全局变量：静态作用域分析的基石

非严格模式下的挑战：
在非严格模式下，x = 10;这样的语句，V8在编译时无法确定x是一个局部变量、一个全局变量，还是一个在作用域链上更高层定义的变量。它必须在运行时进行动态查找，如果找不到，就默认将其创建为全局变量。这种行为：

增加了变量查找的开销： 每次访问或赋值都可能涉及沿着作用域链的动态查找，这比直接访问已知内存位置的局部变量慢得多。
阻碍了寄存器分配和栈帧优化： V8无法将不确定的变量安全地分配到CPU寄存器或优化栈帧上的固定位置，因为它不知道该变量是否可能被意外地提升到全局。
破坏了静态分析： 编译器无法在编译时确定所有变量的生命周期和作用域，导致无法进行许多基于静态分析的优化。

严格模式带来的优势：
严格模式强制所有变量都必须显式声明。这意味着：

确定的变量作用域： V8在编译时就能精确地知道每个变量的作用域（局部、闭包、全局），无需进行昂贵的运行时查找。
高效的变量访问： 局部变量可以被安全地分配到寄存器或栈帧上的固定偏移量，实现极快的访问速度。
增强的静态分析： 编译器可以对代码进行更全面的静态分析，发现潜在错误，并进行更深层次的优化，例如死代码消除和常量传播。

2. 预测性 `this` 绑定：简化调用约定

非严格模式下的挑战：
非严格模式下，函数独立调用时this默认绑定到全局对象，这引入了一个额外的复杂性。V8在编译函数调用时，必须考虑到this可能被隐式绑定的情况。这意味着：

额外的运行时检查： 每次函数调用都可能需要检查this的上下文，以确定是使用提供的上下文，还是回退到全局对象。
阻碍内联： 如果一个函数被频繁调用，V8可能会尝试将其内联到调用点以消除函数调用开销。但this的动态绑定使得内联更加困难，因为内联后的代码需要复制this绑定的逻辑。
多样化的调用模式： 导致V8需要处理更多种类的调用模式，增加了JIT编译器的复杂性。

严格模式带来的优势：
严格模式下，函数独立调用时this为undefined，这使得this的绑定行为变得高度可预测。

简化的调用约定： V8可以假设非方法调用的this始终是undefined，从而简化了函数调用的生成代码，无需额外的检查。
更好的内联机会： 预测性的this行为使得函数内联更加安全和高效，因为this的上下文在编译时可以更好地确定。
Monomorphism (单态性) 优化： V8高度依赖于对象形状和函数调用模式的单态性进行优化。严格模式下this的确定性有助于维持函数的单态调用模式，从而更好地利用Inline Caching等机制。

3. 解耦 `arguments` 对象：优化参数访问

非严格模式下的挑战：
arguments对象与函数参数的双向绑定是V8优化的一个重大障碍。

参数无法优化： 由于修改arguments[i]会影响参数i，反之亦然，V8无法简单地将参数视为独立的局部变量。它必须始终假设参数可能通过arguments对象被修改，或者arguments对象可能通过参数被修改。这意味着：
- 参数不能被直接分配到寄存器，必须保留在栈上或堆上，以便arguments对象可以访问到它们。
- 对参数的读写需要额外的间接寻址，无法像普通局部变量那样直接。
内存开销： arguments对象需要复制参数值或维护与参数的引用关系，增加了内存开销。

严格模式带来的优势：
严格模式下arguments对象与参数的解耦，为V8带来了巨大的性能提升。

参数优化： V8可以将函数参数视为普通的局部变量，将它们分配到CPU寄存器中，或者在栈帧上以固定偏移量存储。这使得参数的访问速度与普通局部变量一样快。
更小的内存占用： arguments对象不再需要与参数保持同步，可以更轻量级地创建。
简化代码生成： JIT编译器可以生成更简单、更直接的代码来处理函数参数。

4. 禁止 `arguments.caller` 和 `arguments.callee`：解锁高级优化

非严格模式下的挑战：
arguments.caller和arguments.callee这两个属性的存在，强制JavaScript引擎保留完整的函数调用栈信息。

阻碍内联： 如果一个函数可以获取其调用者或自身（通过callee），那么V8就不能随意地将这个函数内联到调用点。因为一旦内联，函数本身的“身份”和其调用者的堆栈帧可能就不复存在了，caller/callee将无法正确获取。
阻碍尾调用优化 (TCO)： 尾调用优化是一种重要的性能优化技术，它允许在函数返回时直接跳转到另一个函数的开头，而无需创建新的栈帧。caller/callee的存在使得TCO几乎不可能实现，因为TCO会改变调用栈的结构。
栈帧无法优化： V8不能对函数调用栈帧进行激进的优化（例如，缩减大小、重新组织），因为它必须确保caller/callee能随时访问到正确的、未被修改的栈信息。

严格模式带来的优势：
严格模式下禁止访问arguments.caller和arguments.callee，移除了对V8实现这些高级优化的主要障碍。

增强内联能力： V8可以更自由地进行函数内联，将小函数直接嵌入到调用它们的代码中，消除函数调用的开销。
实现尾调用优化： 尽管在ES6中，尾调用优化仍然需要特定的语法和环境支持，但严格模式消除了其实现的技术障碍，使得V8可以在未来版本中更好地支持TCO。
更灵活的栈帧管理： V8可以对栈帧进行更激进的优化，例如在编译时确定栈帧大小，或者在某些情况下完全消除栈帧，从而减少内存占用和提高执行效率。

5. 限制 `eval` 行为：恢复静态分析能力

非严格模式下的挑战：
非严格模式下eval可以动态地修改当前作用域，这对于V8来说是一个“黑洞”。

静态分析失效： V8无法在编译时确定eval内部可能发生什么，也无法预测eval是否会引入新的变量或修改现有变量。因此，任何包含eval的函数或其外部作用域都可能无法进行静态分析。
保守的代码生成： 即使eval在运行时没有做任何修改，V8也必须假设最坏情况，生成保守的代码，这通常意味着无法进行优化。
阻止优化层级提升： V8的JIT编译器有多个优化层级（如Ignition解释器、TurboFan优化编译器）。如果代码中存在eval，可能会阻止代码从低优化层级提升到高优化层级，或者导致频繁的去优化（deoptimization）。

严格模式带来的优势：
严格模式下eval的独立作用域行为，极大地改善了V8的优化环境。

恢复静态分析： eval不再能修改外部作用域，这意味着V8可以安全地对eval外部的代码进行静态分析和优化，而无需担心eval的副作用。
局部化影响： eval的影响被限制在其自身作用域内，V8可以将其视为一个独立的、不透明的代码块，而不会影响到周围代码的优化。
更有效的优化层级管理： 包含eval的函数仍然可能受到一些限制，但其影响范围被大大缩小，不会波及整个应用程序，使得V8可以更有效地管理代码的优化层级。

6. 禁用 `with` 语句：明确作用域

with语句是JavaScript中一个臭名昭著的性能杀手。它在运行时动态地扩展作用域链，使得V8无法在编译时确定变量的来源。这导致了与eval类似的问题：

阻碍静态分析： 编译器无法确定with块内部的变量是来自with对象还是外部作用域，必须在运行时进行动态查找。
阻止优化： V8无法对包含with语句的代码进行任何有意义的优化，因为它无法预测作用域的变化。

严格模式直接禁用with语句，彻底消除了这个性能陷阱，使得作用域链在编译时就是完全可预测的。

7. 错误报告而非静默失败：提升代码质量与可预测性

虽然这不直接是V8的优化点，但严格模式将许多静默失败的操作（如对只读属性赋值、添加属性到不可扩展对象）转换为抛出错误，对于V8间接有益：

更早发现bug： 开发者在开发阶段就能发现并修复这些错误，而不是让它们在生产环境中默默导致数据不一致或行为异常。
代码行为更可预测： 减少了运行时行为的不确定性，使得V8在生成代码时可以基于更明确的语义进行决策。
鼓励更好的编程实践： 强制开发者编写更规范、更健壮的代码，这本身就减少了需要引擎处理的异常情况。

严格模式与现代JavaScript

值得强调的是，严格模式并非仅仅是一个可选的“插件”。随着ECMAScript语言的不断演进，严格模式已经成为了现代JavaScript的基石。

ES Modules (ESM)： 所有的ES Modules（使用import和export语法的文件）都默认处于严格模式，无需显式声明"use strict";。这是语言设计者明确的选择，旨在推广更健壮、可预测的代码。
Classes： JavaScript中的类（class语法）及其内部的代码也默认处于严格模式。
async / await： 异步函数也默认处于严格模式。

这意味着，如果你正在使用现代JavaScript特性进行开发，你实际上已经置身于严格模式的世界。这进一步巩固了严格模式作为编写高质量、高性能JavaScript代码的默认范式。

总结与展望

严格模式的引入是JavaScript语言走向成熟的关键一步。它通过一套更严格的规则，将语言从“宽容”带向“规范”，极大地提升了代码的健壮性、可预测性和可维护性。

对于V8这类高性能JavaScript引擎而言，严格模式所带来的秩序和确定性，是其进行深度优化的基石。它消除了许多在非严格模式下阻碍优化的语言特性，使得V8能够：

更高效地进行静态作用域分析。
更安全地执行函数内联和尾调用优化。
更有效地管理参数和变量的内存。
更自信地将JavaScript代码编译成高性能的机器码。

因此，无论您是维护遗留代码，还是构建全新的现代应用程序，拥抱严格模式都是一项明智的投资。它不仅能帮助您编写出更少bug、更易维护的代码，更是通向高性能JavaScript应用的关键路径。在未来，随着ECMAScript的不断发展，我们可以预见严格模式所建立的规范化基础，将继续为JavaScript语言和其引擎带来更强大的能力和更卓越的性能。

谢谢大家！