悠悠楠杉
网站页面
CommonJS与ES模块：深度解析两种模块系统的本质差异
08/30
本文深入对比CommonJS与ES模块在加载机制、语法特性、应用场景等维度的核心差异，揭示Node.js生态与现代前端构建工具的模块化演进路径。
在JavaScript的进化历程中，模块化规范如同城市的地下管网，虽不显眼却深刻影响着代码的组织方式。CommonJS与ES模块（ESM）作为两种主流方案，其差异远不止于require与import的表面语法区别。理解它们的本质区别，对构建可维护的现代应用至关重要。
一、设计哲学的分野
CommonJS诞生于2009年的Node.js环境，其核心思想是"动态加载"——模块在代码执行到require()语句时才被加载和执行。这种设计完美契合服务器端场景，允许根据运行时条件动态决定依赖关系。典型场景如：
javascript
// 动态路径加载
const config = require(process.env.NODE_ENV === 'production'
? './config.prod'
: './config.dev')
ES模块则是ECMAScript官方标准（ES6引入），采用"静态解析"模式。模块依赖关系在代码编译阶段就需确定，这种设计带来三个显著优势：
1. 支持Tree Shaking优化
2. 更可靠的循环引用处理
3. 浏览器原生支持
javascript
// 静态导入必须放在顶层
import { capitalize } from './utils.js'
// 报错：不能在条件语句中使用
if (condition) { import './module.js' }
二、运行时机制的深层差异
当执行require('./module')时，CommonJS会经历：
1. 同步加载模块文件
2. 执行模块代码
3. 将module.exports对象缓存
4. 返回缓存结果
这种同步阻塞式加载在服务端不是问题，但在浏览器端会导致性能瓶颈。反观ESM的加载流程：
1. 解析阶段：构建模块依赖图
2. 实例化阶段：建立内存引用
3. 执行阶段：按顺序运行代码
举个实际案例：当模块A和B同时依赖C时，CommonJS可能重复执行C的代码，而ESM保证C只执行一次。
三、循环依赖的处理智慧
循环依赖是检验模块系统的试金石。假设以下场景：
// CommonJS场景
// a.js
exports.loaded = false
const b = require('./b')
exports.loaded = true
// b.js
const a = require('./a')
console.log(a.loaded) // 输出什么？
由于CommonJS的动态特性，此时会输出false——模块状态被"半成品化"。
而在ESM中：
// ESM场景
// a.mjs
let loaded = false
export { loaded }
import { log } from './b.mjs'
loaded = true
// b.mjs
import { loaded } from './a.mjs'
console.log(loaded) // 输出undefined
ESM的静态绑定机制确保所有导入都指向同一内存地址，虽然值可能未初始化，但避免了状态不一致问题。
四、现代开发的最佳实践
- 新项目选择：优先使用ESM，特别是前端项目。Webpack/Rollup等工具已全面支持
- 混合使用策略：
- Node.js可通过
.mjs扩展名或package.json的type字段启用ESM - 使用动态
import()实现按需加载
javascript // 在CommonJS中异步加载ESM const { default: chalk } = await import('chalk')
- Node.js可通过
- 工具链配置：
- Babel配置需包含
@babel/preset-env - TypeScript的
moduleResolution应设为node16或nodenext
- Babel配置需包含
五、未来的模块化格局
随着Node.js 14+对ESM的稳定支持，以及Deno等新运行时原生采用ESM，模块生态正经历深刻变革。但CommonJS仍将在存量NPM包中长期存在——目前约83%的NPM包仍使用CommonJS（2023年统计数据）。这种双轨制格局要求开发者必须掌握两种系统的互操作技巧，如：
- 使用createRequire在ESM中加载CommonJS
- 理解default export与module.exports的自动转换规则
模块化就像编程世界的乐高积木，选择正确的拼接方式，才能构建出既灵活又稳固的系统架构。
