发布于 由admin

CommonJS 的缓存机制：为什么二次 require 得到的对象是同一个？

各位同仁，下午好！

今天，我们将深入探讨 Node.js 中 CommonJS 模块系统的核心机制之一：模块缓存。这是一个看似简单却蕴含深厚设计哲学的机制，它直接决定了我们在 Node.js 应用中管理状态、优化性能以及理解模块行为的关键。我们的核心问题是：为什么对同一个模块进行多次 require 调用时，我们总是得到同一个对象？

要解答这个问题，我们需要一层层拨开 require 函数的神秘面纱，从模块的加载、编译到最终的导出和缓存，全面剖析其内部工作原理。

Node.js 模块系统的基石：CommonJS 规范

在 Node.js 的早期和大部分现有项目中，CommonJS 规范是模块化的基石。它定义了模块如何被定义、导出和导入。其核心思想是：每个文件都被视为一个独立的模块，拥有自己的作用域。

当我们谈论 CommonJS 模块时，最常涉及的两个全局对象就是 module 和 exports。

  • module 对象：代表当前模块的元数据，其中最重要的属性是 module.exports，它定义了当前模块对外暴露的内容。
  • exports 对象：它是 module.exports 的一个引用（在模块代码执行的初始阶段）。通常，我们通过向 exports 对象添加属性来导出多个功能，或者直接替换 module.exports 来导出一个单一的值（例如一个类或一个函数）。
// myModule.js
let counter = 0;

function increment() {
    counter++;
    return counter;
}

function decrement() {
    counter--;
    return counter;
}

console.log('myModule.js is being evaluated!'); // 这行代码在模块首次加载时执行

// 导出多个功能
exports.increment = increment;
exports.decrement = decrement;
exports.currentCounter = () => counter; // 导出当前计数器的getter

在上面的例子中，myModule.js 维护了一个内部状态 counter。它通过 exports 对象对外暴露了几个函数和方法。值得注意的是，console.log 语句会告诉我们模块何时被“评估”或“执行”。

CommonJS 的模块加载是同步的。这意味着当 require('some-module') 被调用时，Node.js 会暂停当前代码的执行，直到 some-module 被完全加载、编译和执行完毕，并返回其导出的内容。这种同步性在服务器端环境中通常不是问题，但在浏览器环境中可能会导致阻塞。

require 函数的幕后之旅：第一次加载

当 Node.js 首次遇到一个 require() 调用时，它会经历一个复杂而精妙的过程。这个过程大致可以分为三个阶段：解析 (Resolution)、加载与编译 (Loading & Compilation) 和 缓存 (Caching)。

1. 模块路径解析 (Module Resolution)

require 函数首先需要确定要加载的模块文件的绝对路径。这个过程被称为模块解析。Node.js 有一套明确的解析规则，它会根据 require 调用中传入的路径字符串来查找对应的文件。

  • 核心模块： 如果传入的字符串是 Node.js 内置的核心模块（如 fs, http, path 等），Node.js 会直接加载其内置的二进制实现。
  • 文件模块：
    • 如果路径以 ./、../ 或 / 开头，Node.js 会将其视为文件路径或目录路径，并尝试在指定位置查找。
    • 它会尝试添加 .js, .json, .node 等常见扩展名。
    • 如果路径指向一个目录，Node.js 会查找该目录下的 package.json 文件。如果 package.json 中定义了 main 字段，则加载 main 字段指定的文件。
    • 如果 package.json 不存在或没有 main 字段，则尝试加载 index.js、index.json 或 index.node。
  • node_modules 模块：
    • 如果路径不包含任何路径前缀（例如 require('lodash')），Node.js 会将它视为一个第三方模块。
    • 它会从当前文件所在的目录开始，逐级向上查找 node_modules 目录，直到文件系统的根目录。
    • 在每个 node_modules 目录中，它会查找与模块名同名的子目录，然后按照文件模块的规则（package.json 的 main 字段或 index.js 等）加载模块。

这个解析过程是同步的，并且非常高效。Node.js 内部维护了一个文件系统缓存，以加速重复的路径查找。

我们可以使用 require.resolve() 函数来查看模块的解析结果，它不会实际加载模块，只会返回模块的绝对路径。

// main.js
console.log('Path module resolved to:', require.resolve('path'));
console.log('Lodash module resolved to:', require.resolve('lodash')); // 假设已安装lodash
// console.log('Non-existent module resolved to:', require.resolve('non-existent-module')); // 会抛出错误

// 假设我们有一个 './utils/helper.js' 文件
// utils/helper.js
// console.log('Helper loaded');

// main.js
console.log('Local helper module resolved to:', require.resolve('./utils/helper.js'));

/*
输出示例:
Path module resolved to: /Users/youruser/nvm/versions/node/v18.17.1/lib/node_modules/path/path.js
Lodash module resolved to: /Users/youruser/my-project/node_modules/lodash/lodash.js
Local helper module resolved to: /Users/youruser/my-project/utils/helper.js
*/

require.resolve 帮助我们理解 Node.js 如何定位模块文件，它是 require 函数内部解析阶段的关键步骤。一旦模块的绝对路径被确定，这个路径将作为模块的唯一标识符（Module ID）在后续的缓存机制中发挥作用。

2. 模块加载与编译 (Module Loading & Compilation)

一旦模块的绝对路径被确定，Node.js 就会执行以下步骤：

  1. 读取文件内容： Node.js 会同步地从磁盘读取模块文件的内容。

  2. 模块包装器 (Module Wrapper)： 这是 CommonJS 模块系统的核心魔法之一。Node.js 不会直接执行模块文件的原始代码。相反，它会将模块的代码用一个函数包装起来。这个包装器函数提供了模块的私有作用域，并注入了 exports、require、module、__filename 和 __dirname 这五个重要的变量，使得它们在模块内部可用。

    这个包装器函数看起来大致如下：

    (function(exports, require, module, __filename, __dirname) {
    // 你的模块代码在这里
    // 例如：
    // let counter = 0;
    // exports.increment = () => counter++;
});

    通过这个包装器，每个 CommonJS 模块都在一个独立的函数作用域中运行，避免了全局变量污染，并确保了模块的封装性。exports、require、module 等变量都是局部于这个函数作用域的，它们是 Node.js 运行时提供的特定实例。

    让我们通过一个简单实验来“揭示”这个包装器：

    // wrapperTest.js
console.log('Is exports === module.exports?', exports === module.exports);
console.log('Type of require:', typeof require);
console.log('Type of module:', typeof module);
console.log('Current filename:', __filename);
console.log('Current dirname:', __dirname);

// 尝试访问全局变量，它不会被污染
// console.log(globalVarDefinedInOtherModule); // Uncaught ReferenceError

    当我们在 Node.js 中运行 node wrapperTest.js 时，你会看到 exports 确实是 module.exports 的一个引用，require 和 module 是可用的对象，并且 __filename 和 __dirname 指向当前模块的文件路径和目录。这些都是包装器函数提供的上下文。

  3. 模块执行： Node.js 会调用这个包装器函数，并将相应的 exports、require、module、__filename 和 __dirname 对象作为参数传入。此时，模块内部的代码开始执行。模块中定义的变量和函数都将局限于这个函数作用域内，除非它们被显式地挂载到 exports 或 module.exports 上。

    在模块执行期间，如果模块内部又调用了 require 来加载其他模块，那么这个过程会递归地重复。

3. 模块导出与缓存 (Module Export and Caching)

当模块代码执行完毕后，module.exports 对象中包含的内容就是该模块最终对外暴露的接口。Node.js 会将这个 module.exports 对象存储在一个内部的缓存中。

这个缓存就是 require.cache。

  • require.cache 是一个 JavaScript 对象，它的键是模块的绝对路径（即前面解析阶段确定的模块 ID），值是对应的 module 对象。
  • 每个 module 对象都有一个 exports 属性，即模块最终导出的内容。
  • module 对象还有一个 loaded 属性，一个布尔值，表示该模块是否已经完成加载和执行。

让我们通过一个具体的例子来观察这个过程：

// moduleA.js
// 这是一个模拟耗时操作，确保我们能观察到模块只执行一次
for (let i = 0; i < 1e7; i++) {} // 模拟一些计算
console.log('ModuleA is being evaluated!');

let count = 0;
exports.increment = () => ++count;
exports.currentCount = () => count;
// main.js
console.log('--- First require call ---');
const modA1 = require('./moduleA.js');
console.log('modA1.currentCount():', modA1.currentCount()); // 0

console.log('--- Second require call ---');
const modA2 = require('./moduleA.js');
console.log('modA2.currentCount():', modA2.currentCount()); // 0

modA1.increment();
console.log('After incrementing via modA1:');
console.log('modA1.currentCount():', modA1.currentCount()); // 1
console.log('modA2.currentCount():', modA2.currentCount()); // 1

console.log('n--- Inspecting require.cache ---');
// 获取 moduleA.js 的绝对路径，这是它在缓存中的键
const moduleAPath = require.resolve('./moduleA.js');
console.log('moduleAPath:', moduleAPath);
console.log('Is moduleA in cache?', !!require.cache[moduleAPath]);
// 我们可以直接访问缓存中的 module 对象
console.log('Cached moduleA exports:', require.cache[moduleAPath].exports);
console.log('Are modA1 and cached exports the same object?', modA1 === require.cache[moduleAPath].exports);

/*
输出示例:
--- First require call ---
ModuleA is being evaluated!
modA1.currentCount(): 0
--- Second require call ---
modA2.currentCount(): 0
After incrementing via modA1:
modA1.currentCount(): 1
modA2.currentCount(): 1

--- Inspecting require.cache ---
moduleAPath: /Users/youruser/my-project/moduleA.js
Is moduleA in cache? true
Cached moduleA exports: { increment: [Function: increment], currentCount: [Function: currentCount] }
Are modA1 and cached exports the same object? true
*/

从上面的输出中，我们可以清晰地看到：

  1. ModuleA is being evaluated! 只输出了一次，这证明 moduleA.js 的代码只被执行了一次。
  2. modA1 和 modA2 尽管是两次 require 调用得到的结果，但它们实际上是同一个对象（通过 modA1.increment() 修改的状态，在 modA2 中也反映了出来）。
  3. modA1 与 require.cache[moduleAPath].exports 严格相等，进一步证实了 require 返回的是缓存中的 module.exports 对象。

核心机制揭秘：二次 require 为何得到同一个对象

现在，我们终于可以直面核心问题了。当 Node.js 遇到一个 require() 调用时，其内部逻辑会遵循一个简单的优先级规则：

  1. 缓存查找优先原则： require 函数在执行任何文件 I/O 或代码编译之前，会首先检查 require.cache 对象。它会根据要加载模块的解析后的绝对路径（Module ID）去查找缓存中是否存在对应的模块。
  2. 模块 ID 与缓存键： 正如我们前面提到的，模块的绝对路径就是其在 require.cache 中的唯一键。
    • 例如，如果 require('./myModule.js') 经过解析得到 /Users/username/project/myModule.js，那么这个字符串就是 require.cache 中的键。
  3. 返回缓存结果：
    • 如果缓存中找到了该模块： require 函数会直接返回 require.cache[moduleID].exports 对象。它不会重新读取文件、重新编译代码，也不会再次执行模块中的任何逻辑。这就是为什么 myModule.js is being evaluated! 只会打印一次的原因。
    • 如果缓存中没有找到该模块： 那么 Node.js 才会执行前面提到的“解析 -> 加载与编译 -> 首次缓存”的完整流程，并将新加载的模块及其导出的内容存入缓存，然后返回该内容。

这个缓存查找优先的原则是 CommonJS 模块缓存机制的核心。它确保了：

  • 性能优化： 避免了重复的文件 I/O 操作和 JavaScript 代码的重复解析与执行，大大提高了应用程序的启动速度和运行时效率。
  • 状态共享与单例模式： 确保了同一个模块在整个应用程序生命周期内只会被加载一次。如果模块内部维护了状态（例如计数器、数据库连接池、配置对象等），那么所有 require 该模块的地方都将共享同一个状态实例。这使得 CommonJS 模块非常适合实现单例模式。

让我们用一个表格来对比首次 require 和后续 require 的流程差异：

| 步骤 | 首次 require('moduleX') | 后续 require('moduleX') CommonJS CommonJS is Node.js for Node.js
common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common common CommonJS CommonJS 的缓存机制：为什么二次 require 得到的对象是同一个？

各位 Node.js 开发者和技术爱好者，大家好！

今天，我们将深入剖析 NodeJS CommonJS 模块系统的核心特性之一：require 函数的缓存机制。这是一个至关重要的细节，它直接影响着我们应用程序的性能、状态管理以及模块的行为模式。我们将解答一个核心问题：为什么对同一个模块路径进行多次 require 调用时，我们总是得到同一个对象？

为了彻底理解这一点，我们将从 CommonJS 模块规范的基础出发，逐步深入到 Node.js 内部的模块加载流程，剖析 require.cache 的作用，并通过丰富的代码示例来验证和巩固我们的理解。

1. CommonJS 模块规范回顾与 require 的作用

在 Node.js 环境中，每个文件都被视为一个独立的模块。CommonJS 规范定义了模块的导入和导出方式，使得开发者可以组织代码，避免全局作用域污染，并实现代码的复用。

核心概念：

  • 模块作用域： 每个 CommonJS 模块都有自己独立的作用域。模块内部定义的变量、函数等，除非显式导出，否则不会暴露给其他模块。

  • module.exports 与 exports：

    • module.exports 是模块对外暴露接口的真正载体。它是一个对象，默认情况下是一个空对象 {}。
    • exports 是 module.exports 的一个引用（在模块代码执行的初始阶段）。通常，我们可以通过向 exports 对象添加属性来导出多个功能。
    • 当需要导出一个单一的值（如一个类、一个函数或一个原始值）时，我们通常会直接赋值给 module.exports，这会切断 exports 和 module.exports 之间的引用关系。

  • require 函数： 这是 Node.js 中用于导入模块的全局函数。它接收一个模块标识符（通常是文件路径或模块名）作为参数，并同步地返回被导入模块导出的内容。

让我们看一个简单的 CommonJS 模块示例：

// lib/my-module.js
console.log('[my-module.js] 模块代码开始执行...');

let privateData = 10; // 模块内部私有状态

function add(a, b) {
    return a + b;
}

function subtract(a, b) {
    return a - b;
}

// 通过 exports 对象导出多个功能
exports.add = add;
exports.subtract = subtract;
exports.version = '1.0.0';

// 也可以直接修改 module.exports，这会覆盖 exports
// module.exports = {
//     myFunction: () => console.log('This is a single function export!')
// };

console.log('[my-module.js] 模块代码执行完毕。');

这个 my-module.js 文件就是一个 CommonJS 模块。当它被 require 时，其中的 console.log 语句会执行，privateData 会被初始化，add、subtract 函数会被定义，并通过 exports 对象对外暴露。

2. require 函数的深层解析：模块加载的完整生命周期

当我们在主文件中首次调用 require('./lib/my-module.js') 时，Node.js 会执行一个详细的模块加载过程。这个过程可以概括为以下几个主要阶段：

2.1. 模块路径解析 (Module Resolution)

这是 require 函数的第一步，也是至关重要的一步。Node.js 必须根据传入的模块标识符确定要加载的模块文件的绝对路径。

Node.js 遵循一套严格的解析算法：

  1. 核心模块优先： 如果标识符是 Node.js 内置的核心模块（如 fs, http, path, util 等），Node.js 会直接加载其内置的 C++ 或 JavaScript 实现，跳过文件系统查找。
  2. 文件路径或目录路径：
    • 如果标识符以 ./、../ 或 / 开头，Node.js 会尝试将其解析为文件或目录路径。
    • 文件： 它会尝试直接加载该文件。如果文件不存在，它会尝试添加常见的扩展名：.js、.json、.node（依次尝试）。
    • 目录： 如果标识符指向一个目录，Node.js 会查找该目录下的 package.json 文件。
      • 如果 package.json 存在且包含 main 字段，则加载 main 字段指定的文件（再次尝试添加扩展名）。
      • 如果 package.json 不存在或没有 main 字段，则尝试加载 index.js、index.json 或 index.node。
  3. node_modules 查找：
    • 如果标识符既不是核心模块，也不是相对/绝对路径（例如 require('lodash')），Node.js 会将其视为一个第三方模块或包。
    • 它会从当前模块文件所在的目录开始，逐级向上查找名为 node_modules 的目录。
    • 在每个 node_modules 目录中，它会查找与模块标识符同名的子目录。
    • 一旦找到，它会按照上述“目录路径”的规则（package.json 的 main 字段或 index.js 等）加载模块。

示例：使用 require.resolve()

require.resolve() 是一个非常有用的工具，它允许我们模拟 require 函数的解析过程，返回模块的绝对路径，但不会实际加载和执行模块代码。

// main.js
const path = require('path');
const fs = require('fs');

console.log('--- 模块路径解析示例 ---');

// 1. 核心模块
console.log('Path module resolved to:', require.resolve('path')); // 输出 Node.js 内置 path 模块的路径

// 2. 第三方模块 (假设你已安装 'lodash')
try {
    console.log('Lodash module resolved to:', require.resolve('lodash'));
} catch (e) {
    console.log('Lodash not found, please install with `npm install lodash`');
}

// 3. 本地文件模块
// 创建一个文件 './modules/util.js'
// modules/util.js
// module.exports = { greet: () => 'Hello from util!' };
fs.mkdirSync('./modules', { recursive: true });
fs.writeFileSync('./modules/util.js', "module.exports = { greet: () => 'Hello from util!' };");
console.log('Local util module resolved to:', require.resolve('./modules/util.js'));

// 4. 本地目录模块 (假设有 './modules/calculator/index.js')
// modules/calculator/index.js
// module.exports = { add: (a, b) => a + b };
fs.mkdirSync('./modules/calculator', { recursive: true });
fs.writeFileSync('./modules/calculator/index.js', "module.exports = { add: (a, b) => a + b };");
console.log('Local calculator directory module resolved to:', require.resolve('./modules/calculator'));

// 清理创建的测试文件
fs.rmSync('./modules', { recursive: true, force: true });

/*
可能的输出:
--- 模块路径解析示例 ---
Path module resolved to: /usr/local/lib/node_modules/path/path.js
Lodash module resolved to: /Users/youruser/your-project/node_modules/lodash/lodash.js
Local util module resolved to: /Users/youruser/your-project/modules/util.js
Local calculator directory module resolved to: /Users/youruser/your-project/modules/calculator/index.js
*/

一旦模块的绝对路径被确定，这个路径就成为了该模块在 Node.js 运行时中的唯一标识符（Module ID）。这个 Module ID 将是后续缓存机制中的关键。

2.2. 模块加载与编译 (Module Loading & Compilation)

在解析阶段确定了模块的绝对路径后，Node.js 会执行以下步骤来加载和编译模块：

  1. 读取文件内容： Node.js 会同步地从磁盘读取模块文件的完整内容（以字符串形式）。

  2. 模块包装器 (Module Wrapper)： 这是 CommonJS 模块实现其独立作用域的关键。Node.js 不会直接执行读取到的原始 JavaScript 代码。相反，它会将模块的代码用一个特殊的函数包装起来。这个包装器函数提供了一个私有作用域，并向模块代码注入了五个重要的局部变量：exports, require, module, __filename, 和 __dirname。

    这个包装器函数的结构大致如下：

    (function(exports, require, module, __filename, __dirname) {
    // 模块的原始代码在这里被插入
    // 例如：
    // console.log('[my-module.js] 模块代码开始执行...');
    // let privateData = 10;
    // exports.add = (a, b) => a + b;
});

    通过这种包装，模块内部的所有变量和函数都局限于这个函数作用域，不会污染全局环境，同时又能方便地访问到 require、exports 等 Node.js 提供的模块化工具。

  3. 模块执行： Node.js 接下来会调用这个包装器函数，并将当前模块对应的 exports 对象、require 函数、module 对象以及 __filename 和 __dirname 字符串作为参数传递进去。此时，模块的实际代码开始执行。

    在模块执行期间：

    • 模块内部可以定义变量和函数。
    • 模块可以通过 exports 或 module.exports 来设置对外暴露的接口。
    • 模块内部也可以调用 require 来导入其他模块，这会触发一个递归的加载过程。

2.3. 模块导出与缓存 (Module Export and Caching)

当模块的包装器函数执行完毕，即模块代码完全运行结束后，module.exports 对象中包含的内容就是该模块最终对外暴露的接口。Node.js 会将这个 module.exports 对象存储在一个内部的缓存中。

这个缓存就是 require.cache。

  • require.cache 是一个普通的 JavaScript 对象，它存储了所有已加载模块的引用。
  • 缓存键 (Key)： 缓存的键是模块的绝对路径（即前面解析阶段确定的 Module ID）。
  • 缓存值 (Value)： 缓存的值是对应的 Module 对象本身。这个 Module 对象包含了模块的元数据，其中最重要的就是 exports 属性，它持有该模块最终导出的内容。Module 对象还有一个 loaded 属性（布尔值），表示模块是否已完成加载和执行。
// lib/cached-module.js
console.log('[cached-module.js] 模块被首次评估！'); // 观察此行只输出一次
let counter = 0;
exports.increment = () => ++counter;
exports.getCurrent = () => counter;
// main.js
console.log('--- 首次 require 调用 ---');
const mod1 = require('./lib/cached-module.js');
console.log('mod1.getCurrent():', mod1.getCurrent()); // 0

console.log('n--- 检查 require.cache ---');
// 获取模块的绝对路径，作为缓存键
const modulePath = require.resolve('./lib/cached-module.js');
console.log('cached-module.js 的绝对路径:', modulePath);

// 检查缓存中是否存在
const cachedModuleEntry = require.cache[modulePath];
console.log('缓存中是否存在该模块:', !!cachedModuleEntry); // true
if (cachedModuleEntry) {
    console.log('缓存中的 exports 对象:', cachedModuleEntry.exports);
    console.log('mod1 === cachedModuleEntry.exports?', mod1 === cachedModuleEntry.exports); // true
    console.log('缓存中的 Module 对象是否已加载:', cachedModuleEntry.loaded); // true
}

console.log('n--- 第二次 require 调用 ---');
const mod2 = require('./lib/cached-module.js'); // 注意：不会再次打印 "模块被首次评估！"
console.log('mod2.getCurrent():', mod2.getCurrent()); // 0

mod1.increment(); // 通过 mod1 修改模块内部状态
console.log('n--- 通过 mod1 调用 increment 后 ---');
console.log('mod1.getCurrent():', mod1.getCurrent()); // 1
console.log('mod2.getCurrent():', mod2.getCurrent()); // 1 (mod2 也看到了状态变化)

console.log('mod1 === mod2?', mod1 === mod2); // true

// 清理测试文件
const fs = require('fs');
fs.rmSync('./lib', { recursive: true, force: true });

/*
输出示例:
--- 首次 require 调用 ---
[cached-module.js] 模块被首次评估！
mod1.getCurrent(): 0

--- 检查 require.cache ---
cached-module.js 的绝对路径: /Users/youruser/your-project/lib/cached-module.js
缓存中是否存在该模块: true
缓存中的 exports 对象: { increment: [Function: increment], getCurrent: [Function: getCurrent] }
mod1 === cachedModuleEntry.exports? true
缓存中的 Module 对象是否已加载: true

--- 第二次 require 调用 ---
mod2.getCurrent(): 0

--- 通过 mod1 调用 increment 后 ---
mod1.getCurrent(): 1
mod2.getCurrent(): 1
mod1 === mod2? true
*/

从这个详细的示例中，我们清晰地观察到：

  1. [cached-module.js] 模块被首次评估！ 这条日志只在第一次 require 调用时出现，证实了模块代码只执行一次。
  2. mod1 和 mod2 确实是同一个对象实例（mod1 === mod2 为 true）。
  3. 通过 mod1 修改模块内部状态后，这种变化也通过 mod2 反映出来，这进一步证明了它们共享同一个底层模块实例。
  4. mod1 严格等于 require.cache 中存储的 exports 对象，这揭示了 require 返回值的来源。

3. require.cache：缓存机制的核心

require.cache 是一个全局对象，它扮演着 CommonJS 模块系统缓存的心脏角色。它的结构是一个简单的键值对映射：

  • 键 (Key)： 模块的绝对路径。
  • 值 (Value)： 完整的 Module 对象。

每个 Module 对象至少包含以下关键属性：

  • id: 模块的绝对路径（与缓存键相同）。
  • exports: 模块最终导出的内容。这就是 require 函数的返回值。
  • parent: 引用这个模块的父模块。
  • filename: 模块文件的绝对路径。
  • loaded: 一个布尔值，表示模块是否已完成加载和执行。
  • children: 一个数组，包含这个模块所 require 的所有子模块。

require 函数的完整逻辑流程（简版）：

  1. 解析模块标识符，得到模块的绝对路径 moduleID。
  2. 检查 require.cache[moduleID]：
    • 如果存在： 直接返回 require.cache[moduleID].exports。
    • 如果不存在：
      a. 创建一个新的 Module 实例，并将其存储到 require.cache[moduleID]。
      b. 读取模块文件内容。
      c. 用包装器函数包裹模块代码。
      d. 执行包裹后的模块代码。
      e. 将 module.exports 的最终值赋给 require.cache[moduleID].exports。
      f. 将 require.cache[moduleID].loaded 设置为 true。
      g. 返回 require.cache[moduleID].exports。

通过这个流程，Node.js 确保了任何模块在整个应用生命周期中，只要其模块 ID 相同，就只会被加载和执行一次。后续对相同模块的 require 调用都将从 require.cache 中获取其导出的 exports 对象。

3.1. 手动操作 require.cache：一个双刃剑

理论上，我们可以直接操作 require.cache 对象。例如，我们可以删除缓存中的某个模块条目，从而强制 Node.js 在下次 require 时重新加载该模块。

// lib/reset-module.js
console.log('[reset-module.js] 模块被评估！');
let value = Math.random(); // 每次评估生成一个新随机数
exports.getValue = () => value;
// main.js
const path = require('path');
const fs = require('fs');

fs.mkdirSync('./lib', { recursive: true });
fs.writeFileSync('./lib/reset-module.js', `
    console.log('[reset-module.js] 模块被评估！');
    let value = Math.random();
    exports.getValue = () => value;
`);

console.log('--- 第一次加载 ---');
const modA = require('./lib/reset-module.js');
console.log('modA.getValue():', modA.getValue()); // 会得到一个随机数

console.log('n--- 第二次加载 (从缓存) ---');
const modB = require('./lib/reset-module.js');
console.log('modB.getValue():', modB.getValue()); // 得到和 modA 相同的值 (因为是从缓存读取)
console.log('modA === modB?', modA === modB); // true

console.log('n--- 清除缓存并重新加载 ---');
const modulePathToClear = require.resolve('./lib/reset-module.js');
delete require.cache[modulePathToClear]; // 从缓存中删除该模块

console.log('缓存已清除。');
console.log('--- 第三次加载 (强制重新加载) ---');
const modC = require('./lib/reset-module.js'); // 此时会再次打印 "[reset-module.js] 模块被评估！"
console.log('modC.getValue():', modC.getValue()); // 得到一个新的随机数
console.log('modA === modC?', modA === modC); // false

// 清理测试文件
fs.rmSync('./lib', { recursive: true, force: true });

/*
输出示例:
--- 第一次加载 ---
[reset-module.js] 模块被评估！
modA.getValue(): 0.7328994840822607

--- 第二次加载 (从缓存) ---
modB.getValue(): 0.7328994840822607
modA === modB? true

--- 清除缓存并重新加载 ---
缓存已清除。
--- 第三次加载 (强制重新加载) ---
[reset-module.js] 模块被评估！
modC.getValue(): 0.1234567890123456
modA === modC? false
*/

警告： 手动操作 require.cache 是一种非常规的做法，通常只在开发环境中的热重载、测试或非常特殊的场景下使用。在生产环境中，随意清除缓存可能会导致意外的行为、性能问题和内存泄漏，因为它可能破坏模块之间预期的状态共享和单例模式。通常，Node.js 应用程序的生命周期中不建议清除缓存。

4. 缓存机制的设计哲学：为什么这样做？

Node.js 采用 CommonJS 缓存机制并非偶然，它背后蕴含着深刻的设计考量和优势：

  1. 性能优化：

    • 避免重复文件 I/O： 读取文件是磁盘操作，相对耗时。缓存机制确保文件只被读取一次。
    • 避免重复代码解析与编译： 将 JavaScript 源代码解析成抽象语法树（AST）并编译成字节码也是一个计算密集型过程。缓存避免了这些重复工作。
    • 避免重复模块执行： 模块内部可能包含复杂的初始化逻辑、数据库连接、网络请求等。重复执行这些逻辑会浪费资源并降低性能。

  2. 状态共享与单例模式：

    • 这是缓存机制最重要的副作用（也是其有意为之的特性）。当一个模块被 require 时，它的 module.exports 对象被缓存。所有后续对该模块的 require 调用都将获得对同一个 exports 对象的引用。
    • 这意味着如果一个模块维护了内部状态（例如一个配置对象、一个计数器、一个数据库连接池、一个事件发射器等），那么所有导入该模块的消费者都将共享这个状态。这非常适合实现应用程序中的单例服务或配置管理。

    • 示例：日志服务

      // services/logger.js
console.log('[logger.js] 初始化日志服务...');
const logBuffer = [];
exports.log = (message) => {
    const entry = `${new Date().toISOString()} - ${message}`;
    logBuffer.push(entry);
    console.log(entry);
};
exports.getLogs = () => [...logBuffer]; // 返回副本，防止外部修改
      // app.js
const logger = require('./services/logger.js');
const anotherComponent = require('./components/anotherComponent.js'); // 假设也 require 了 logger

logger.log('应用启动');
anotherComponent.doSomething(); // 假设这个方法也会调用 logger.log
logger.log('应用关闭');

console.log('n所有日志：');
logger.getLogs().forEach(log => console.log(log));

      在这个例子中，无论 logger 被 require 多少次，logBuffer 都是同一个数组实例。所有模块都会向同一个 logBuffer 写入日志，确保了日志的集中管理。

  3. 内存效率： 避免创建重复的模块对象和作用域，减少了内存占用。

  4. 防止副作用重复发生： 模块的初始化逻辑（例如，注册事件监听器、启动后台任务等）通常只需要执行一次。缓存机制保证了这些副作用不会在每次 require 时重复触发。

5. CommonJS 模块的特殊考量

尽管缓存机制带来了诸多好处，但在某些情况下，我们也需要理解其可能带来的影响。

5.1. 循环依赖 (Circular Dependencies)

当模块 A 依赖模块 B，同时模块 B 也依赖模块 A 时，就形成了循环依赖。CommonJS 模块系统以一种特殊的方式处理这种情况：

  • 当 A require B 时，B 开始加载。
  • 在 B 执行过程中，如果 B require A，此时 A 尚未完全加载完毕（module.loaded 为 false）。
  • Node.js 会直接返回 A 当前已导出的 exports 对象（一个未完成填充的对象）。
  • B 继续执行，然后完成加载并将其 exports 缓存。
  • A 继续执行，并最终完成加载，其 exports 也会被填充完毕。

示例：

// circularA.js
console.log('[A] circularA.js 开始加载');
exports.name = 'Module A'; // A 模块先导出 name
exports.aFunction = () => {
    console.log('[A] aFunction 被调用');
    const b = require('./circularB.js'); // 此时 B 正在加载中
    console.log('[A] 在 aFunction 中访问 B 的 name:', b.name); // 可能会得到 undefined
    // 如果 b.bFunction 依赖 A 的完整导出，这里也可能出现问题
};
console.log('[A] circularA.js 导出完成');
// circularB.js
console.log('[B] circularB.js 开始加载');
exports.name = 'Module B'; // B 模块先导出 name
exports.bFunction = () => {
    console.log('[B] bFunction 被调用');
    const a = require('./circularA.js'); // 此时 A 正在加载中
    console.log('[B] 在 bFunction 中访问 A 的 name:', a.name);
    a.aFunction(); // 可能会导致无限循环或错误，如果 aFunction 又 require b
};
const a = require('./circularA.js'); // 这里的 a 可能会是一个不完整的 exports 对象
console.log('[B] 在模块级别访问 A 的 name:', a.name);
console.log('[B] circularB.js 导出完成');
// main.js
const fs = require('fs');
fs.writeFileSync('./circularA.js', `
    console.log('[A] circularA.js 开始加载');
    exports.name = 'Module A';
    exports.aFunction = () => {
        console.log('[A] aFunction 被调用');
        const b = require('./circularB.js');
        console.log('[A] 在 aFunction 中访问 B 的 name:', b.name);
    };
    console.log('[A] circularA.js 导出完成');
`);
fs.writeFileSync('./circularB.js', `
    console.log('[B] circularB.js 开始加载');
    exports.name = 'Module B';
    exports.bFunction = () => {
        console.log('[B] bFunction 被调用');
        const a = require('./circularA.js');
        console.log('[B] 在 bFunction 中访问 A 的 name:', a.name);
    };
    const a = require('./circularA.js');
    console.log('[B] 在模块级别访问 A 的 name:', a.name);
    console.log('[B] circularB.js 导出完成');
`);

console.log('--- 启动主程序 ---');
const modA = require('./circularA.js');
modA.aFunction();

// 清理文件
fs.rmSync('./circularA.js');
fs.rmSync('./circularB.js');

/*
输出示例:
--- 启动主程序 ---
[A] circularA.js 开始加载
[A] circularA.js 导出完成
[B] circularB.js 开始加载
[B] 在模块级别访问 A 的 name: Module A // 这里 A 已经导出 name
[B] circularB.js 导出完成
[A] aFunction 被调用
[A] 在 aFunction 中访问 B 的 name: Module B // B 此时也已完成导出
*/

在上面的例子中，[B] 在模块级别访问 A 的 name: Module A 证明了 circularA 在被 circularB require 时，其 exports.name 已经可用。这是因为 circularA 在 require('./circularB.js') 之前已经设置了 exports.name = 'Module A';。

关键点： CommonJS 循环依赖的处理方式是，当一个模块被另一个模块 require 时，它会返回当前已填充的 exports 对象，即使模块尚未完全执行完毕。这意味着，如果一个模块在它依赖的模块完全加载之前，尝试访问该依赖模块的某个属性，它可能会得到 undefined 或一个不完整的对象。因此，设计模块时应尽量避免复杂的循环依赖。

5.2. exports 和 module.exports 的细微差别

之前我们提到 exports 默认是 module.exports 的一个引用。但这种引用关系是可以被破坏的。

  • 保持引用： 如果我们通过 exports.propertyName = value; 的方式导出，那么 exports 和 module.exports 仍然是同一个对象。 
    // moduleC.js
exports.a = 1;
module.exports.b = 2;
// 此时 module.exports 是 { a: 1, b: 2 }
  • 断开引用： 如果我们直接给 module.exports 赋值（例如 module.exports = someValue;），那么 exports 就不再指向最终的导出对象。require 函数只会返回 module.exports 的最终值。 
    // moduleD.js
exports.oldValue = 'This will be ignored'; // exports 仍然指向原来的空对象
module.exports = {
    newValue: 'This is the actual export'
};
// 此时 require('./moduleD.js') 会得到 { newValue: 'This is the actual export' }
// exports 对象中的 oldValue 将不会被导出

    最佳实践： 为了避免混淆和潜在错误，通常建议在一个模块中只使用一种导出风格：要么始终通过 exports.property = value 来添加属性，要么始终通过 module.exports = someValue 来完全替换导出对象。不要混用。

6. 与 ES Modules 的对比 (简要)

虽然我们主要讨论 CommonJS，但简要提及 ES Modules (ESM) 的不同之处有助于加深理解。ESM 是 JavaScript 官方的模块化标准，在 Node.js 中通过 .mjs 文件或在 package.json 中设置 "type": "module" 来支持。

特性 CommonJS Modules (CJS) ES Modules (ESM)
加载方式 同步加载 (require) 异步加载 (import)
绑定方式 值拷贝 (Value Copy)：导入的是导出时的一个副本。但对于对象，导入的是对象的引用，因此对导入对象的修改会影响原始对象。 实时绑定 (Live Binding)：导入的是对原始模块变量的引用。当原始模块中的值改变时，导入方也能看到这种变化。
执行时机 运行时加载和执行 静态分析，在代码执行前完成解析和绑定
顶层作用域 模块有自己的函数作用域 ((function(...){...})) 模块有自己的文件作用域，没有额外的函数包装
缓存机制 基于 require.cache 缓存 module.exports 对象的引用。 基于模块注册表缓存模块的实例。 模块同样只执行一次，保证单例。
循环依赖 返回一个不完整的 exports 对象 严格处理，在绑定阶段就能检测，并提供未初始化状态的引用

虽然 ESM 也有其自身的缓存机制（确保模块只执行一次），但其“实时绑定”的特性使得 ESM 在处理导出值的变化时，行为与 CommonJS 有所不同。对于对象而言，CommonJS 导入的也是引用，所以对对象的修改会影响原始对象；但对于原始值（如数字、字符串），ESM 可以做到实时更新，而 CommonJS 导入的是一个副本。

7. CommonJS 缓存机制的实践意义

深入理解 CommonJS 的缓存机制，对于我们日常的 Node.js 开发具有重要的实践意义：

  • 设计单例服务： 缓存机制是实现单例模式的天然基础。例如，数据库连接池、日志记录器、配置管理器等，都应该设计为单例，以确保整个应用程序共享同一个实例。
  • 避免意外状态共享： 如果一个模块不应该共享状态（例如，一个工厂函数每次都应该返回新的实例），那么就不能直接导出带有可变状态的对象。你需要确保每次 require 时返回一个新的实例，例如通过导出一个工厂函数。
  • 优化应用程序启动时间： 意识到模块只加载一次，可以帮助我们优化模块的初始化逻辑，避免不必要的开销。
  • 理解错误行为： 当你在应用程序中遇到奇怪的状态不一致问题时，检查是否是由于误解了模块缓存和状态共享导致的。

总结

CommonJS 模块的缓存机制是 Node.js 高效、可靠运行的基石。通过将模块的 exports 对象缓存到 require.cache 中，Node.js 确保了对同一模块的多次 require 调用总是返回同一个对象实例。这一设计不仅极大地提升了性能，避免了重复的文件 I/O 和代码执行，更重要的是，它为 Node.js 应用程序提供了强大的状态共享能力，使得单例模式的实现变得自然而简洁。深入理解这一机制，能帮助我们编写更健壮、性能更优、更易于维护的 Node.js 应用程序。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注