CommonJS模块在Node.js中同步加载，即阻塞式文件读取与立即执行，虽提升调试直观性但导致冷启动慢、缓存失效风险及循环依赖隐患；可通过延迟加载、合并小模块、预加载等优化规避瓶颈。
CommonJS模块在Node.js中是同步加载的，这和浏览器端的ES模块异步加载有本质区别。同步加载让代码逻辑更直观、调试更简单，但也带来一些性能上的隐含成本，尤其在大型应用或冷启动场景中。
同步加载的本质：阻塞式文件读取与立即执行
CommonJS的require()调用会立即触发以下步骤：
- 同步解析模块路径（包括查找
node_modules、处理package.json的main字段等） - 同步读取文件内容（底层调用
fs.readFileSync） - 将源码包装成函数并执行（即“模块包装器”：
(function(exports, require, module, __filename, __dirname) { ... })） - 缓存
module.exports结果到require.cache，后续相同路径的require直接返回缓存值
这意味着每个require都会真实地“停住当前线程”，直到模块加载并执行完毕。虽然Node.js主线程在I/O密集型场景中本就应避免阻塞，但CommonJS的设计把这种阻塞当作可接受的权衡——换来了确定性、可预测性和开发体验。
性能关键点：冷启动慢、缓存失效、循环依赖隐患
同步加载带来的性能影响主要体现在三类典型场景：
-
冷启动延迟高：服务刚启动时，大量
require层层加载，尤其当依赖树深、模块体积大（如含大量JSON配置、大型工具库）时，同步读取+编译+执行会明显拖慢启动时间 -
require.cache被手动清除或绕过：例如测试中频繁
delete require.cache[...]再重载模块，会导致重复读取和执行；或使用vm.runInThisContext等绕过模块系统，失去缓存优势 -
循环依赖导致未完成导出：A
requireB，B又requireA，此时A中module.exports可能还是空对象（仅初始化了exports引用），造成运行时行为不符合预期——这不是性能问题，但常因同步执行顺序暴露逻辑缺陷
优化建议：不改机制，但可规避瓶颈
你无法把CommonJS变成异步，但可以减少它的开销：
-
延迟加载（Lazy require）：把非首屏/非必需模块移到函数内部
require，比如CLI工具中只在对应命令执行时才加载子命令模块 -
合并小模块：避免为几行工具函数单独建文件，减少
fs调用次数和模块包装开销（V8对小函数的优化也更好） -
预编译或提前加载关键路径：在服务就绪前（如health check阶段）主动
require核心模块，把缓存“热起来” -
警惕
require动态字符串：如require(somePath + '.js')不仅无法被静态分析，还可能绕过缓存或引入安全风险，也增加路径解析负担
对比ES模块：为什么Node.js仍支持CommonJS
ES模块（import）在Node.js中是异步+静态分析的，支持顶层await、真正的树摇、更优的循环依赖处理。但它要求明确的文件扩展名或"type": "module"，且不兼容require.cache等运行时控制能力。CommonJS保留至今，是因为它更适合Node.js传统生态——尤其是配置加载、插件系统、运行时条件加载等需要动态性和灵活性的场景。两者共存不是过渡，而是分工。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
