如何识别CommonJS与ESM加载机制同步异步差异的方法详解

CommonJS采用同步加载，ESM使用异步加载——两者核心区别在于加载过程是否阻塞主线程：CJS的require会立即同步读取并执行模块，而ESM的import会触发三阶段异步流程（加载/链接/求值），支持静态分析与顶层await。

“CommonJS是同步加载，ESM是异步加载”——这句话本身没有错，但听起来总感觉不够透彻，甚至容易产生误导。问题的本质，其实不在于“是否阻塞”这个表面现象，而在于加载行为是否会让JavaScript的主线程停下来等待I/O操作完成。这背后，反映出两套完全不同的运行时设计哲学。

CommonJS 的同步特性：真实阻塞，立即执行

在Node.js环境中，当你调用require()时，它绝不会让步。它会立即、同步地完成三个步骤：

• 同步解析路径：搜索node_modules、读取package.json，每一步都必须完成。
• 同步读取文件：本质上调用fs.readFileSync，文件未读完，后续代码无法继续执行。
• 立即包装并执行：将模块代码包装成函数，当场调用，执行结果直接放入exports对象。

整个过程，主线程的控制权始终被牢牢占据，不会释放。这导致一个典型现象：如果模块依赖链很深，执行流会被一层层“卡住”，直到最底层的require返回结果。这也是为什么CommonJS应用冷启动相对较慢，以及处理循环引用时，你有时拿到的是一个尚未完全初始化的exports对象。

ESM 的异步特性：不阻塞，但具有确定性顺序

相比之下，ESM的import语句就显得“优雅”得多。它本身不会暂停当前脚本的执行，但会触发一个由规范明确定义的三阶段异步流程：

• 加载（Load）：异步获取模块源码。在浏览器中发起fetch请求，在Node.js中则调用异步的fs.readFile。
• 链接（Link）：同步建立导出与导入之间的内存绑定关系。注意，这个阶段必须等待所有依赖模块都完成加载（Load）后才能开始。
• 求值（Evaluate）：异步执行模块的顶层代码。执行顺序严格按照依赖关系的拓扑排序，叶子模块优先执行，整个过程由微任务队列调度。

因此，当你看到“a.mjs模块先打印日志，然后导入它的模块才打印”这类现象时，不要误会。这并不是因为import在同步等待，而是整个模块图的“求值”阶段被宿主环境自动地await了，从而形成了一个在语义上完全可预测的执行顺序。

快速识别加载机制的方法

实际上，要快速判断一个模块属于哪种体系，根本不需要查阅厚厚的文档。观察以下几个特征即可：

• 能否写在条件语句里？：if (x) require('./a') ✅ 这是CommonJS典型的动态性；if (x) import './a' ❌ 静态import语句不允许这样写（动态import()函数可以）——这本身就是ESM异步加载和静态分析特性的体现。
• 模块顶层代码何时执行？：CJS模块一旦被require就立刻执行；ESM模块仅在首次import触发的“求值”阶段执行一次。
• 错误何时抛出？：CJS在require瞬间，如果文件找不到就会直接抛错；ESM则分阶段：加载失败会拒绝Promise，链接或求值阶段出错也会在对应时机抛出错误。

实际影响：不仅仅是“快慢”，更是行为差异

同步与异步的深层区别，远不止影响加载速度这样简单，它直接塑造了模块的运行逻辑和生态工具的行为：

• 循环引用的处理：CJS返回的是当前已经赋值了的exports对象（可能是一个“半成品”）；ESM建立的是“实时绑定”，即使导出值尚未被赋值，导入方拿到的也是一个指向未来值的引用，从根本上避免了未定义状态。
• 顶层await的支持：ESM允许在模块顶层直接使用await（配合动态import()或异步初始化逻辑），这极大便利了代码组织；CJS则完全不支持，必须将异步逻辑封装进函数中。
• 工具链的兼容与优化：打包器（如Webpack、Vite）可以对ESM进行可靠的静态依赖分析，从而实现高效的Tree Shaking；而CJS动态的require语句常常让这些优化手段无从下手。

说到底，选择CJS还是ESM，早已不是一个简单的语法偏好问题，而是关乎应用架构、性能表现和未来兼容性的核心决策。理解它们加载机制的本质差异，就是做出正确选择的第一步。