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.jsconst { 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.mjsimport { 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.jsasync 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 引用）：这是两者之间一个非常重要的，也常常让人混淆的差异点。
以上就是什么是CommonJS和ES模块？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1518824.html
微信扫一扫 
支付宝扫一扫 
