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