前端JavaScript模块化发展史：从CommonJS到ES Module

JavaScript 最初诞生于网景浏览器，旨在为静态网页添加简易交互，语言底层未配备模块化组织方案。随着单页应用（SPA）与复杂业务逻辑的爆发式增长，前端开发历经了从“立即执行函数沙箱封装”、Node.js 带动的“CommonJS 规范”、浏览器端的“AMD/CMD/UMD 探索”，直至 ECMAScript 官方确立“ES Module（ESM）”标准的过程。本文全面梳理这一技术变迁路线，深度对比各阶段规范的运行机制与设计取舍，帮助开发者透彻掌握现代模块化工程的核心原理。

一、早期无规范时代的模块雏形：命名空间与立即执行函数

在 ECMAScript 2015（ES6）之前，JavaScript 仅具备全局作用域与函数作用域。若在一个页面中引入多个 <script> 标签，所有脚本声明的顶层变量与函数都会直接暴露在全局对象 window 上。

随着多人协同开发与脚本体积膨胀，全局污染带来了两个致命问题：一是极其容易发生命名冲突，后加载的脚本会静默覆盖先前定义的函数；二是代码间缺乏显式的依赖关系，开发者必须人工确保依赖顺序正确排列，否则就会出现 Uncaught ReferenceError: xxx is not defined 错误。

1. 命名空间模式（Namespace Pattern）

早期为了减小冲突范围，社区普遍采用对象字面量来构造“命名空间”，将所有的属性与函数绑定至单个全局对象上：

// 挂载至全局对象，收敛污染范围
var MyApp = window.MyApp || {};

MyApp.utils = {
  formatDate: function(date) {
    return date.toISOString().slice(0, 10);
  }
};

这种方式虽然将全局变量数量压缩到单个对象，但内部属性依然完全公开，任何外部代码都可以随意修改甚至重写 MyApp.utils 中的方法，缺乏私有作用域和数据封装能力。

2. 立即执行函数表达式（IIFE）与模块模式

为了实现真正的私有成员封装，开发者开始利用 JavaScript 函数闭包（Closure）的特性，创造了立即执行函数表达式（Immediately Invoked Function Expression, IIFE）。通过在闭包内声明私有状态，仅对外返回暴露特定接口的对象，现代模块化的核心理念在此初具雏形：

// 利用 IIFE 构造独立作用域，实现数据私有化
var CounterModule = (function () {
  var count = 0; // 私有变量，外部不可直接读取与修改

  function logState() {
    console.log("Current count:", count);
  }

  return {
    increment: function () {
      count++;
      logState();
    },
    reset: function () {
      count = 0;
      logState();
    }
  };
})();

CounterModule.increment(); // 输出: Current count: 1
console.log(CounterModule.count); // 输出: undefined（成功防范外部篡改）

IIFE 解决了私有变量保护与命名空间污染的问题，但其局限性依然明显：模块之间的依赖依旧强依赖 HTML 中 <script> 标签的声明顺序。如果一个项目包含数十个文件，人工维护依赖拓扑图将变得极易出错且维护成本极高。

图 1：前端 JavaScript 模块化技术演进路线全景

二、服务端率先破局：CommonJS 规范与 Node.js

2009 年，Ryan Dahl 发布了 Node.js，JavaScript 正式跨出浏览器沙箱迈入服务器端编程。服务器端需要操作操作系统文件、数据库连接与网络套接字，若没有标准化的文件拆分与模块管理机制，构建工业级后端程序是不可能的。在此背景下，针对服务端场景的 CommonJS 规范应运而生。

1. CommonJS 的基本规范与用法

CommonJS 规定每个独立文件就是一个模块，具有独立的私有作用域。模块内通过全局注入的 require() 函数同步导入依赖，通过 module.exports 或 exports 导出公开变量与函数。

// math.js - 模块定义
const factor = 2;

function multiply(val) {
  return val * factor;
}

module.exports = {
  multiply: multiply
};

// app.js - 模块引用与使用
const math = require('./math');
console.log(math.multiply(5)); // 输出: 10

2. 为什么 CommonJS 无法直接在浏览器端工作？

CommonJS 的核心设计建立在“同步加载与本地磁盘 I/O”的假定之上：

• 在 Node.js 中，执行 const fs = require('fs') 或 require('./file') 时，模块直接从本地 SSD 或内存缓存中读取，耗时极短（通常微秒级），同步阻塞主线程几乎感觉不到停顿。
• 但在浏览器端，JavaScript 脚本必须通过网络 HTTP 请求从远程服务器异步下载。如果使用同步的 require()，主渲染线程将在请求返回之前被彻底卡死，导致整个页面无响应（假死），用户体验将发生断崖式下跌。

三、浏览器端的分支探索：AMD、CMD 与 UMD

为了解决浏览器端异步拉取模块代码的需求，前端社区在 2010 年前后分化出了专门面向浏览器环境的模块化规范。

1. AMD（Asynchronous Module Definition）与 RequireJS

AMD 规范由 RequireJS 推广开来。其核心原则是“依赖前置，异步加载”。所有依赖必须在模块定义时通过数组显式声明，浏览器会并发下载这些文件，全部加载完成后触发回调函数执行：

// AMD 规范模块定义
define(['jquery', 'lodash'], function($, _) {
  // 当 jquery 与 lodash 均在网络端下载完成后，执行该工厂函数
  function renderList(items) {
    return $('<ul>').append(_.map(items, function(i) {
      return $('<li>').text(i);
    }));
  }

  return {
    render: renderList
  };
});

AMD 解决了浏览器端网络异步加载的阻塞问题，但缺点在于语法冗长，开发者必须在文件最顶层显式维护长串依赖数组，且模块会无差别提前加载执行，无法根据逻辑分支实现按需实例化。

2. CMD（Common Module Definition）与 Sea.js

由国内阿里巴巴前端专家玉伯（玉伯也即 Sea.js 作者）主导的 CMD 规范，提出了“就近依赖，延迟执行”的理念。语法风格尽可能贴近 CommonJS：

// CMD 规范模块定义
define(function(require, exports, module) {
  var a = require('./a'); // 只有在执行到此处时才执行模块 a
  a.doSomething();

  if (needSpecialFeature) {
    var b = require('./b'); // 按需加载与执行
    b.doSomething();
  }
});

Sea.js 会在模块执行前通过正则表达式静态扫描模块内部代码中所有的 require(...) 语句，提前把网络文件抓取到本地，但在代码真正运行到 require 语句前不初始化执行。

3. UMD（Universal Module Definition）：跨环境兼容方案

随着模块化方案的割裂，开源库作者面临巨大痛点：同一个工具函数库，既想让 Node.js 开发者 require()，又想让浏览器端 AMD 开发者引用，还想让通过 <script> 标签引入的普通网页能够挂在 window 上。

UMD（通用模块定义）应运而生。它不是一个全新的加载器，而是一段精巧的 IIFE 工厂胶水代码，自动检测当前宿主环境并挂载：

(function (root, factory) {
  if (typeof define === 'function' && define.amd) {
    // 1. 如果存在 AMD 规范的 define 函数，注册为 AMD 模块
    define(['b'], factory);
  } else if (typeof module === 'object' && module.exports) {
    // 2. 如果存在 CommonJS 的 module.exports，注册为 Node/CommonJS 模块
    module.exports = factory(require('b'));
  } else {
    // 3. 否则作为普通全局变量挂载至 window 或 global
    root.myModule = factory(root.b);
  }
}(typeof self !== 'undefined' ? self : this, function (b) {
  return { version: '1.0.0' };
}));

图 2：CommonJS 的值拷贝模型与 ES Module 的只读引用绑定对比

四、语言级正统标准：ES Module (ES6 / ESM)

2015 年 6 月，ECMAScript 2015（ES6）正式发布，从语言语法层面对模块化进行了标准化定义。ES Module（简称 ESM）的设计目标非常明确：提供一种能够同时适用于浏览器与服务器端、支持静态优化且语法简明优雅的通用标准。

1. 静态声明语法：import 与 export

ES Module 在语法层面上禁止了动态拼接引入路径（动态 import() 作为补充提案除外），要求所有 import 声明必须置于文件顶层：

// 命名导出 (Named Exports)
export const apiEndpoint = "https://api.example.com";
export function fetchData() { /* ... */ }

// 默认导出 (Default Export)
export default class UserService {
  // 每个模块至多只能有一个 default 导出
}

// 统一命名导入与默认导入
import UserService, { apiEndpoint, fetchData as fetchApi } from './user.js';

2. 浏览器原生支持：<script type="module">

现代主流浏览器已全部提供对 ESM 的原生支持。只需在 HTML 中为 <script> 增加 type="module" 属性，浏览器即可按模块机制解析：

<!-- 原生加载 ES 模块 -->
<script type="module" src="./main.js"></script>

<!-- 针对不支持 ESM 的旧版浏览器提供优雅降级 -->
<script nomodule src="./dist/bundle-fallback.js"></script>

原生 type="module" 具有以下关键行为特性：

• 默认异步延迟执行：模块脚本默认具备类似于 defer 的效果，会在 HTML 文档解析完成后、DOMContentLoaded 触发前按照依赖顺序依次执行，不会阻碍 DOM 树的解析构建。
• 严格模式强制开启：模块内部自动运行在严格模式（'use strict'）下，顶层 this 指向 undefined 而非 window。
• CORS 跨域约束：通过网络拉取的模块脚本必须正确配置 CORS 响应头，否则浏览器将拒绝执行。

图 3：现代 JavaScript 引擎解析与执行 ES Module 的三个核心阶段

五、深度解构：CommonJS 与 ES Module 的关键技术差异

CommonJS 与 ES Module 并非仅仅是语法糖的差异（require 与 import），两者在底层设计哲学、编译期行为以及内存管理上存在本质的区别。

1. 静态结构 vs 动态执行（Static vs Dynamic）

• CommonJS 是动态执行的：可以在条件判断、函数调用甚至模板字符串中随时调用 require(dynamicPath)。代码在真正运行到这一行之前，引擎根本无法获知当前模块依赖了哪些外部文件。
• ES Module 是静态结构的：import 声明必须出现在顶层，路径必须是字面量字符串，不能置于 if 分支内部。这种强制约束使打包工具（如 Rollup、Webpack、Vite）在不执行代码的前提下，仅通过静态词法分析（AST）就能建立整个项目的依赖拓扑树。

2. 静态分析赋能的“Tree Shaking”（摇树优化）

正是因为 ES Module 具备确定性的静态结构，打包工具才能在编译阶段精准识别出哪些导出变量从未被任何外部模块引用，进而在最终构建产物中安全地将其移除（Dead Code Elimination）：

// utilities.js
export function add(a, b) { return a + b; }
export function unusedHeavyCalc() { /* 包含大量未被使用的代码 */ }

// index.js
import { add } from './utilities.js';
console.log(add(1, 2));

// 经过 Vite / Rollup 构建后：
// unusedHeavyCalc 会被完整剔除，最终产物体积极小。
// 换作 CommonJS，打包器无法确信运行期间是否会执行 module.exports[someVar]，因此不敢贸然删除代码。

3. 值的浅拷贝 vs 动态只读引用（Live Binding）

这是两者在运行时最关键的语义差异。以下代码清晰展示了不同规范对状态更新的处理方式：

// -------------------- CommonJS 场景 --------------------
// count-cjs.js
let count = 1;
function increment() { count++; }
module.exports = { count, increment };

// main-cjs.js
const { count, increment } = require('./count-cjs');
console.log(count); // 输出: 1
increment();
console.log(count); // 输出依然为: 1！（count 作为基本类型被拷贝进了本模块的作用域，与原模块脱节）

// -------------------- ES Module 场景 --------------------
// count-esm.js
export let count = 1;
export function increment() { count++; }

// main-esm.js
import { count, increment } from './count-esm.js';
console.log(count); // 输出: 1
increment();
console.log(count); // 输出变为: 2！（实时只读引用直接映射原模块内存，状态变化完全可见）
// count = 10; // Uncaught TypeError: Assignment to constant variable.（外部不允许主动篡改引用）

4. 循环引用的处理机制

在大型复杂工程中，模块 A 依赖模块 B、模块 B 反向依赖模块 A 的情况屡见不鲜：

• CommonJS 的应对方案：当发生循环引用时，CJS 不会报错，而是直接返回当前已执行部分的 module.exports 导出快照。尚未执行的代码对应的属性将返回 undefined。
• ES Module 的应对方案：ESM 借助预先分配的内存指针表（Live Binding），先建立变量符号绑定，允许模块互相引用导出名。只有当代码执行到暂时性死区（TDZ）尚未初始化的 let/const 变量时，才会抛出 ReferenceError，处理逻辑更为确定与严谨。

六、现代工程中的双模块共存与互操作实践

尽管 ES Module 已经成为语言标准与现代工具链（Vite、Rollup）的默认选择，但 npm 生态中依然沉淀了上百万基于 CommonJS 构建的经典第三方依赖包。在实际工程落地时，正确处理二者的互操作是每位前端工程师的必修课。

1. Node.js 中的模块类型声明

Node.js 从 v12.x 版本开始全面支持原生 ES 模块。区分一个文件是 CJS 还是 ESM 遵循以下仲裁规则：

• 若文件扩展名为 .mjs，则无条件视为 ES Module。
• 若文件扩展名为 .cjs，则无条件视为 CommonJS。
• 若文件扩展名为普通 .js，Node.js 会向上查找最近的 package.json，读取 "type" 字段。如果指定了 "type": "module"，该目录下的 .js 文件全部作为 ESM 执行；未指定或设置为 "type": "commonjs" 时，则默认作为 CJS 解析。

2. ESM 导入 CommonJS 的边界陷阱

在 ES Module 中导入 CommonJS 模块时，可以采用默认导入（Default Import），但不能随意解构未命名的属性：

// 正确做法：将 CommonJS 导出的 module.exports 作为一个整体默认对象引入
import lodash from 'lodash';
console.log(lodash.cloneDeep({ a: 1 }));

// 潜在风险：尝试命名解构引入
// 在部分 Node.js 原生环境下，以下写法可能会触发：
// SyntaxError: The requested module 'lodash' does not provide an export named 'cloneDeep'
import { cloneDeep } from 'lodash'; 

// 解决方案：采用动态解构或通过现代打包工具（如 Rollup 的 @rollup/plugin-commonjs）进行抹平

3. 动态导入：import() 函数

为了弥补 ESM 静态语法无法按需执行的不足，ECMAScript 补充了返回 Promise 的动态导入表达式 import(specifier)。它不受顶层声明限制，可运行在任何异步流程中，是现代前端实现路由懒加载与代码分包（Code Splitting）的基石：

// 根据条件在运行时按需拉取特定模块
button.addEventListener('click', async () => {
  try {
    const { renderChart } = await import('./analytics-chart.js');
    renderChart();
  } catch (err) {
    console.error("模块加载失败：", err);
  }
});

图 4：主流 JavaScript 模块化规范多维度综合对比总结矩阵

七、总结与技术选型建议

JavaScript 模块化的演进历程，本质上是前端工程复杂度不断上升、开发规模从单兵作战转向大型团队协作的必然产物。从最初利用函数闭包实现简易数据私有化，到 CommonJS 首次确立规范化文件模块标准，再到 AMD/CMD 在浏览器端异步场景下的过渡探索，最终由 ECMAScript 官方从语言层面推出了集大成者 ES Module。

结合当前前端工具链生态（Vite、Webpack 5、Rollup、Bun 等），针对不同项目类型的选型建议如下：

• 新建前端应用（Web / SPA）：100% 推荐使用 ES Module 作为主开发规范。利用 Vite 或构建工具的原生 ESM 开发服务器获得秒级热更新（HMR），并在生产构建中充分享受 Tree Shaking 带来的体积压缩红利。
• 开发开源工具库或 npm 包：推荐采用双导出模式（Dual Package Hazard Prevention）。源码完全采用 ESM 编写，借助构建工具产出 ESM（供现代打包器优先使用，在 package.json 中配置 "exports": { "import": "..." }）与 CJS（在 "exports": { "require": "..." } 中提供兼容，服务于尚未升级的传统 Node.js 用户）。
• Node.js 后端服务项目：新项目可在 package.json 中声明 "type": "module" 全面拥抱 ESM，直接使用顶层 await 与标准导入；已有大型遗留项目则可继续稳定运行在 CommonJS 模式下，按需引入动态 import() 实现对新兴纯 ESM 依赖库的渐进式过渡。