CJS与ESM加载机制：同步还是异步？

CJS与ESM看似只是“同步 vs 异步”的加载方式差异，实则深刻影响模块行为、错误时机、循环引用处理、顶层await支持及构建优化能力——CJS的require会真实阻塞主线程、立即读取并执行代码，导致冷启动慢和半初始化exports风险；而ESM的import虽不阻塞执行，却通过规范定义的Load/Link/Evaluate三阶段异步流程，实现可预测的依赖排序、实时绑定、静态分析友好和更健壮的模块化语义，理解这一本质区别，远比记住“一个同步一个异步”更能帮你写出可靠、高效且未来兼容的JavaScript代码。

CommonJS 是同步加载，ESM 是异步加载——这句话没错，但容易误导。关键不在“是否阻塞”，而在于加载行为是否让 JS 主线程停等 I/O 完成。

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

在 Node.js 中，require() 会立刻做三件事：

• 同步解析路径（查 node_modules、读 package.json）
• 同步读取文件（fs.readFileSync）
• 立即包装并执行模块代码（生成函数并调用）

整个过程不交出主线程控制权。哪怕模块依赖很深，也会一层层卡住执行流，直到所有 require 都返回结果。这也是为什么冷启动慢、循环引用时可能拿到未初始化的 exports。

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

import 语句本身不暂停执行，但它触发的是一个规范定义的三阶段异步流程：

• Load：异步获取源码（浏览器发 fetch，Node.js 调 fs.readFile）
• Link：同步建立导出/导入的内存绑定，但必须等所有依赖 Load 完成才开始
• Evaluate：异步执行顶层代码，严格按依赖拓扑排序（叶子模块优先），由微任务队列调度

你看到 “a.mjs 先打印，再打印 importer”，不是因为 import 同步等待，而是整个模块图的 Evaluate 阶段被宿主自动 await，形成语义上可预测的顺序。

一眼识别加载机制的方法

不用翻文档，看这几处就能快速判断：

• 能否在条件语句里写：if (x) require('./a') ✅ 是 CommonJS；if (x) import('./a') ❌ 静态 import 不允许，动态 import() 才行 —— 这是 ESM 异步加载的体现
• 模块内顶层代码执行时机：CJS 模块一 require 就执行；ESM 模块只在首次 import 触发的 Evaluate 阶段执行，且只执行一次
• 错误抛出时机：CJS 在 require 时抛错（如文件不存在）；ESM 的 Load 阶段失败会拒绝 Promise，但 Link 或 Evaluate 失败也分别对应不同错误阶段

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

同步与异步的深层区别，直接影响运行逻辑：

• 循环引用处理：CJS 返回当前已赋值的 exports 对象（可能是半成品）；ESM 建立的是实时绑定，即使未求值也能安全导入（import { x } from './a' 拿到的是将来会被赋值的 x 的引用）
• 顶层 await 支持：ESM 允许 await 在模块顶层（配合 import() 或异步初始化）；CJS 不支持，必须包进函数
• 工具链兼容：打包器（如 Webpack、Vite）对 ESM 可做静态分析、tree-shaking；CJS 的动态 require 会让这些优化失效

以上就是《CJS与ESM加载机制：同步还是异步？》的详细内容，更多关于的资料请关注golang学习网公众号！