悠悠楠杉
网站页面
JavaScript模块化：CommonJS与ESModule对比_js工程化
12/02
在现代JavaScript开发中，模块化早已成为不可或缺的基础设施。无论是构建大型前端应用，还是编写可维护的后端服务，良好的模块设计都能显著提升代码的可读性与复用性。而在众多模块规范中，CommonJS 与 ES Module（简称 ESM）无疑是影响最深远的两种。它们分别代表了不同时代的技术选择，也反映了JavaScript语言本身的发展轨迹。
CommonJS诞生于2009年，最初是为了解决服务器端JavaScript缺乏标准模块系统的问题。它被Node.js广泛采用，并迅速成为后端JavaScript开发的事实标准。其核心思想非常直观：每个文件是一个独立的模块，通过require()同步加载依赖，通过module.exports或exports暴露接口。例如：
js
// math.js
function add(a, b) {
return a + b;
}
module.exports = { add };
// app.js
const { add } = require('./math');
console.log(add(2, 3)); // 5
这种写法简单直接，特别适合Node.js这种运行在本地文件系统的环境。由于模块是同步加载的，开发者可以像操作普通变量一样使用导入的内容，调试和理解逻辑也相对容易。然而，这种同步加载机制在浏览器环境中却成了致命伤——网络请求具有延迟，若采用同步方式会阻塞页面渲染，严重影响用户体验。
随着Web应用日益复杂，社区迫切需要一种更适合浏览器的模块方案。于是，ES6（ECMAScript 2015）正式引入了原生的模块系统——ES Module。它采用import和export关键字，语法更加声明式且具备静态结构。例如：
js
// math.mjs
export function add(a, b) {
return a + b;
}
// app.mjs
import { add } from './math.mjs';
console.log(add(2, 3));
ESM最大的优势在于其“静态性”。import语句必须位于模块顶层，不能动态写在条件判断或函数内部（早期限制），这使得工具可以在不执行代码的情况下进行静态分析，实现摇树优化（Tree Shaking）、循环依赖检测、类型检查等高级功能。这也是现代前端构建工具如Webpack、Vite能够高效工作的基础。
另一个关键区别在于加载机制。CommonJS是运行时动态加载，模块值是复制或引用的快照；而ESM是编译时静态链接，且采用“实时绑定”（live binding）。这意味着即使模块内部修改了导出变量的值，导入方也能立即感知变化。例如：
js
// counter.mjs
let count = 0;
export const increment = () => ++count;
export { count };
// main.mjs
import { count, increment } from './counter.mjs';
console.log(count); // 0
increment();
console.log(count); // 1，自动更新
这种行为在某些场景下非常有用，但也要求开发者更清楚模块状态的共享机制。
在工程化实践中，两者的共存带来了不少挑战。Node.js直到v12版本才稳定支持ESM，且需通过.mjs扩展名或package.json中设置"type": "module"来启用。而许多npm包仍以CommonJS格式发布，导致开发者常面临互操作问题。虽然Node允许在ESM中通过import()动态导入CommonJS模块，但无法进行静态分析，影响构建性能。
当前趋势已明显向ESM倾斜。现代前端框架（React、Vue）、构建工具、CDN服务均优先支持ESM。越来越多的库开始提供双格式输出，兼顾兼容性与现代化需求。对于新项目，推荐直接采用ESM作为默认模块系统，尤其在使用Vite、Snowpack等基于浏览器原生模块的工具链时，能充分发挥其按需加载、快速热更新的优势。
归根结底，CommonJS与ES Module并非简单的替代关系，而是适应不同运行环境的合理演进。理解它们的设计哲学与技术差异，有助于我们在实际开发中做出更明智的架构决策，推动JavaScript工程化向更高层次发展。
