CommonJS采用同步加载和值拷贝，模块导出的是静态值；ES模块支持异步加载和动态引用，导出绑定保持实时更新，两者在加载机制、缓存策略及变量绑定上存在本质差异。
CommonJS和ES模块是JavaScript中两种主要的模块化规范，它们定义了代码如何被组织、导入和导出。CommonJS主要用于Node.js环境，采用同步加载；而ES模块是ECMAScript官方标准，支持异步加载，广泛应用于浏览器和现代Node.js。
讲到JavaScript的模块化，我总觉得这像是一场语言自身进化史上的重要篇章。一开始，我们的JS代码都是全局变量满天飞，命名冲突是家常便饭。后来，为了管理这种混乱，社区开始探索各种模式，比如IIFE（立即执行函数表达式），但这终究不是一个统一的解决方案。CommonJS和ES模块的出现，正是为了解决这个核心痛点：如何优雅、高效地组织和复用代码。
CommonJS，这个名字一听就知道它和“通用”计算有关。它诞生在服务器端，主要是Node.js的天下。它的核心思想是：每个文件都是一个独立的模块。你通过
require()来导入模块，通过
module.exports或
exports来导出。这种模式是同步加载的，也就是说，当你
require一个模块时，它会立即执行并返回结果。这在服务器端很合理，因为文件都在本地磁盘上，读取速度快，同步加载并不会造成太大的性能瓶颈。
举个例子：
// math.js (CommonJS 模块)
function add(a, b) {
return a + b;
}
module.exports = { add };
// app.js
const { add } = require('./math');
console.log(add(2, 3)); // 输出 5这种模式简洁有效，让Node.js的生态系统迅速壮大。
然而，当JavaScript开始大规模进军浏览器端时，CommonJS的同步加载就显得力不从心了。浏览器需要从网络加载资源，同步加载会阻塞页面渲染，用户体验会非常糟糕。于是，ES模块（ECMAScript Modules），或者我们常说的ESM，应运而生，它被设计成JavaScript的官方模块标准，从一开始就考虑到了异步加载的需求。
ESM使用
import和
export关键字。它的加载是异步的，并且支持静态分析，这意味着工具可以在代码运行前就确定模块的依赖关系，这对于tree-shaking（摇树优化，移除未使用的代码）和更好的性能优化至关重要。
// math.mjs (ES 模块)
export function add(a, b) {
return a + b;
}
// app.mjs
import { add } from './math.mjs';
console.log(add(2, 3)); // 输出 5注意到文件扩展名了吗？
.mjs是Node.js中用来明确标识ES模块的常见做法，尽管现在也可以通过
package.json中的
"type": "module"来统一处理。
所以，核心区别在于：CommonJS是Node.js的产物，同步加载，运行时确定依赖；ES模块是JS官方标准，异步加载，编译时确定依赖。它们各自有其历史背景和适用场景，但现在，整个生态都在朝着ES模块的方向靠拢。
为什么Node.js同时支持CommonJS和ES模块，这带来了哪些挑战？
Node.js作为JavaScript的运行时环境，一开始就选择了CommonJS作为其模块系统。这在当时是完全合理的，也极大地推动了Node.js的普及。但随着ES模块成为ECMAScript的官方标准，Node.js也面临了一个不可避免的问题：如何拥抱这个新标准，同时又不破坏现有的CommonJS生态？这是一个巨大的挑战，因为这两种模块系统在设计理念、加载机制、作用域处理上都有本质的区别。
最直接的挑战是互操作性。你不可能一夜之间把所有CommonJS模块都转换成ES模块，反之亦然。这就需要一个机制，让这两种模块能够相互调用。Node.js采取了一些策略：
-
默认 CommonJS： 除非你明确告诉Node.js一个文件是ES模块（比如使用
.mjs
扩展名，或者在package.json
中设置"type": "module"
），否则它会默认将其视为CommonJS模块。 -
ESM 导入 CommonJS： 在ES模块中，你可以通过
import CJSModule from 'cjs-module';
这样的语法导入CommonJS模块。但要注意，CommonJS模块的module.exports
会被视为ES模块的默认导出。具名导出则无法直接导入，需要一些变通方法。 -
CommonJS 导入 ESM： 这就有点棘手了。CommonJS是同步加载的，而ESM是异步的。直接
require()
一个ES模块是行不通的。Node.js提供了一个动态import()
函数，它返回一个Promise，允许CommonJS模块以异步的方式加载ES模块。// cjs-app.js async function main() { const { add } = await import('./math.mjs'); // 动态导入 console.log(add(5, 5)); } main();这种方式虽然解决了问题，但引入了异步性，使得代码结构变得复杂。
另一个挑战是模块解析机制。CommonJS的
require路径解析规则和ESM的
import解析规则有所不同，尤其是对待文件扩展名和目录索引文件（如
index.js）的方式。这导致在混合使用时，开发者需要特别注意路径的写法，避免出现“找不到模块”的错误。
再者，作用域和this
行为也有差异。CommonJS模块内部的
this指向
module.exports，而ES模块顶层的
this是
undefined，更接近严格模式。这些细微的差别在迁移或混合开发时，如果不注意，很容易引入难以调试的bug。
这种双重支持虽然带来了灵活性，但也无疑增加了Node.js生态的复杂性，让初学者感到困惑，也让老开发者在项目迁移或新项目选型时需要深思熟虑。我们现在正处于一个过渡期，理解这些差异和挑战，对于编写健壮、可维护的Node.js应用至关重要。
CommonJS和ES模块在加载机制、缓存与绑定上的核心差异是什么？
深入理解CommonJS和ES模块，不能只停留在
require/exports和
import/export的语法层面，它们底层的加载机制、模块缓存以及变量绑定的方式，才是真正决定它们行为差异的关键。
加载机制： CommonJS采用的是同步加载。这意味着当Node.js遇到
require()语句时，它会暂停当前模块的执行，去加载、编译并执行被请求的模块，然后返回其
module.exports对象，之后当前模块才继续执行。这种方式简单直接，但在网络IO密集的场景下（比如浏览器），会导致严重的阻塞。
ES模块则采用异步加载。它的加载过程分为三个阶段：
- 构建（Construction）： 查找、下载并解析模块，构建模块记录（Module Record）。
- 实例化（Instantiation）： 将模块与内存中的实际值绑定，但不执行代码。
- 求值（Evaluation）： 运行模块代码，填充导出值。 这个过程是异步的，并且可以并行进行。浏览器可以预先加载模块的依赖，提高效率。这种设计使得ES模块天生适合在浏览器环境中工作，也为Tree Shaking等优化提供了可能。
模块缓存： 两种模块系统都支持模块缓存，以避免重复加载和执行。
-
CommonJS： 当一个模块被
require()
加载后，它的module.exports
对象会被缓存起来。后续再次require()
同一个模块时，会直接返回缓存中的对象，而不会重新执行模块代码。这个缓存是基于文件路径的。 - ES模块： ES模块的缓存机制更为精细。一旦模块被加载并实例化，它的模块记录就会被缓存。这包括模块的导出绑定。即使模块代码再次被请求，也只会返回已缓存的绑定。
变量绑定（值拷贝 vs 引用）： 这是两者之间一个非常重要的，也常常让人混淆的差异点。
