---

---

前言

模块系统是 JavaScript 生态演化的核心部分，不同的模块规范（CJS/AMD/UMD/ESM）针对不同的运行环境设计，它们的加载机制、语法规则和构建工具处理方式都有显著差异。本文将结合具体案例，详细解析它们的设计初衷、运行环境适配、构建工具转换规则，并解释为什么需要不同的打包策略。

---

一、CommonJS (CJS) - Node.js 的同步模块系统

1.1 设计背景

1. 目标环境：Node.js（服务器端）
2. 核心需求：同步加载模块，无需考虑网络延迟。(设计初衷是 Node.js 的本地文件系统)
3. 关键特性：
   require() 同步阻塞：模块立即执行。
   module.exports 导出模块：用于模块化开发。
   模块缓存：相同路径的 require() 只执行一次。

1.2 浏览器兼容性问题

• 为什么浏览器不能直接运行 CJS？

// 浏览器直接运行会报错！
const fs = require('fs'); // Uncaught ReferenceError: require is not defined

原因：

1. API 不兼容：require 是 Node.js 的 API，浏览器没有实现。
2. 加载方式差异：CJS 是同步加载，浏览器需要异步加载（否则阻塞渲染）。

1.3 Webpack 如何转换 CJS

// 原始代码 (CJS)
const lodash = require('lodash');
// Webpack 转换后（简化版）
const __webpack_modules__ = {'lodash': (module) => { module.exports = _; }
};
function __webpack_require__(moduleId) {// 1. 检查缓存// 2. 执行模块代码// 3. 返回 module.exports
}
const lodash = __webpack_require__('lodash');

关键转换策略

• 包裹模块：每个模块被包裹成函数，避免全局污染。
• 实现自己的 require 系统：webpack_require 模拟 Node.js 的模块加载。
• 依赖分析：构建时静态分析 require() 调用。

1.4 适用场景

1. Node.js 后端开发：适用于服务器端的模块化开发。
2. 旧版工具链：如 Webpack 4 默认使用 CJS。

二、AMD (Asynchronous Module Definition) - 浏览器异步加载方案

2.1 设计背景

1. 目标环境：浏览器（RequireJS）
2. 核心需求：异步加载，避免阻塞渲染
3. 关键特性：
   define() 定义模块
   require([], callback) 动态加载依赖
   依赖前置：所有依赖必须在回调函数之前声明

独立模块立即执行，依赖模块按序加载、回调执行

2.2 为什么现代浏览器不原生支持 AMD

<!-- 必须手动加载 RequireJS -->
<script src="require.js"></script>
<script>require(['jquery'], function($) {// 回调函数内才能使用 jQuery});
</script>

原因：

1. AMD 是社区规范，不是 ECMAScript 标准
2. 现代浏览器原生支持 ESM，不再需要 AMD

2.3 Webpack/Rollup 如何处理 AMD

// 原始 AMD 代码
define(['jquery'], function($) {return { init: () => $('body').css('color', 'red') };
});
// Webpack 转换后（Promise 化）
__webpack_require__.e("jquery").then(function() {const $ = __webpack_require__("jquery");return { init: () => $('body').css('color', 'red') };
});

关键转换策略：

• 转为 Promise 链：适配现代异步编程
• 代码拆分：动态加载的模块会被拆分为单独 chunk

2.4 适用场景

1. 旧版浏览器项目（IE 8+）
2. 按需加载的复杂 SPA（如 2015 年前的 AngularJS 项目）

三、UMD (Universal Module Definition) - 兼容浏览器 + Node.js 的"缝合怪"

3.1 设计背景

1. 目标环境：同时支持浏览器、Node.js、AMD
2. 核心需求：一份代码，多环境运行(适配所有规范)
3. 关键特性：
   环境嗅探：判断当前是 CJS/AMD/全局变量
   手动适配：通过 if-else 实现多环境兼容

3.2 为什么 UMD 代码看起来这么"丑"

// UMD 模板代码（jQuery 风格）
(function (global, factory) {if (typeof define === 'function' && define.amd) {// AMD 环境define(['jquery'], factory);} else if (typeof exports === 'object') {// CJS 环境 (Node.js)module.exports = factory(require('jquery'));} else {// 浏览器全局变量global.myLib = factory(global.jQuery);}
}(typeof self !== 'undefined' ? self : this, function ($) {// 实际模块代码return { init: () => $('body').css('color', 'red') };
}));
</script>

原因：

1. 需要手动判断运行环境
2. 必须兼容多种模块加载方式

3.3 构建工具如何生成 UMD

# Rollup 生成 UMD
rollup -i src/index.js -o dist/bundle.umd.js -f umd -n myLib

// 输出结构
(function (global, factory) {// 环境检测逻辑...
})(this, function() {return /* 模块内容 */;
});

关键转换策略：

• 包裹 IIFE（Immediately Invoked Function Expression，立即调用函数表达式）：避免污染全局作用域
• 注入环境判断：运行时动态选择模块系统

3.4 适用场景

1. 开源库开发（如 Lodash、Moment.js）
2. 需要同时支持<script>标签和 npm 安装的项目

传统浏览器用户：希望通过<script src="awesome-lib.js">直接使用
现代前端工程：希望通过 npm install awesome-lib 引入

用户环境不可控，而 UMD 就是最好的兼容方案
当使用 RollupWebpack 之类的打包器时，UMD 通常用作备用模块

四、ES Modules (ESM) - 现代 JavaScript 标准

4.1 设计背景

1. 目标环境：现代浏览器 + Node.js（ES6+）
2. 核心需求：官方标准、静态分析、Tree Shaking
3. 关键特性：
   import / export 语法
   静态加载：依赖关系在编译时确定
   原生支持：浏览器和 Node.js 均可直接运行

静态分析（Static Analysis）是编程语言和构建工具在 不实际执行代码的情况下，通过分析代码的结构、语法、依赖关系来推导代码行为的技术。它在 Tree Shaking（摇树优化）中扮演核心角色，直接影响打包工具的无用代码消除能力。

静态分析是 现代前端工具链的基石

• Tree Shaking 能安全删除未使用代码
• 类型系统 能提前发现错误
• 压缩工具 能极致优化体积

CJS 的动态特性破坏了静态分析的前提，而 ESM 的严格静态结构让工具能精确推导代码行为。这就是为什么现代前端生态（Vite/Rollup/Snowpack）都基于 ESM 设计。

模块系统	静态分析可行性	根本原因
ESM	✅ 完美支持	语言标准强制静态结构
CJS	⚠️ 有限支持	require() 动态性破坏分析前提
AMD	✅ 基础支持	依赖数组显式声明
UMD	❌ 几乎不可用	混合模式导致逻辑分裂
SystemJS	❌ 不可用	动态注册机制

4.2 为什么旧浏览器不支持 ESM

<!-- 现代浏览器 -->
<script type="module">import { add } from './math.js'; // 正常工作
</script>
<!-- 旧浏览器 -->
<script>import { add } from './math.js'; // SyntaxError
</script>

原因：

1. import/export 是 ES6 语法，IE 11 及更早版本不支持
2. 传统 <script> 默认是全局脚本，不解析模块语法

4.3 构建工具如何处理 ESM

webpack：

// 原始 ESM
import React from 'react';
// Webpack 转换后（CJS 风格）
const React = __webpack_require__('react');

• 策略：默认转为 CJS，兼容旧环境

Vite：

// 开发模式：直接返回 ESM
import React from '/node_modules/react/index.js'; // 浏览器发起请求
// 生产模式：Rollup 打包
import { r as React } from './chunk-abc123.js';

• 策略：
  开发模式：开发时不需要打包，利用浏览器原生 ESM
  生产模式：Rollup 打包优化

ESM 的模块处理机制与传统 AMD/CJS 有本质区别，主要体现在编译时静态分析与运行时执行控制两个阶段。

4.4 ESM 模块生命周期的三个阶段

(1) 解析阶段（Parsing）
静态分析所有 import（无论是否会被执行）

// main.js
import { unused } from './unused.js'; // 即使从未使用也会被分析
import { core } from './core.js';
if (false) unused(); // 死代码

构建不可变的依赖图：

(2) 加载阶段（Loading）
浏览器/Node.js 的行为：

• 立即并行请求所有依赖模块（包括unused.js）
• 阻塞性：必须所有依赖加载完成才会进入执行阶段

示例网络请求：
GET /main.js
GET /unused.js (并行)
GET /core.js   (并行)

(3) 执行阶段（Evaluation）
严格按拓扑顺序初始化（从叶子节点开始）：

执行顺序：unused.js → core.js → main.js
关键特性：
即使模块导出未被使用，该模块仍会被执行（包括其顶层代码）
但不会执行未被调用的函数

模块初始化 ≠ 导出被调用
即使导出未被使用，模块的顶层代码仍会执行(打包工具可能通过Tree Shaking移除)

4.5 适用场景

1. 现代前端项目（React/Vue 3+）
2. Node.js 14+ 后端项目

五、模块系统对比总结

模块系统	加载方式	环境支持	构建工具转换策略	典型应用场景
CJS	同步	Node.js	包裹为函数，模拟 require	Node.js 后端
AMD	异步	浏览器 (RequireJS)	转为 Promise + 代码拆分	旧版浏览器 SPA
UMD	兼容多种	浏览器 + Node.js	IIFE + 环境嗅探	开源库开发
ESM	静态	现代浏览器 + Node	原生支持或转为 CJS	现代前端/Node 项目

特性	ESM	AMD/RequireJS	CommonJS
依赖获取时机	并行请求所有发现的依赖	按需并行请求	同步阻塞加载
执行触发条件	整个依赖图就绪后拓扑序执行	串行回调（按照申明顺序）	遇到 require 时立即执行
循环依赖处理	语言标准明确定义（引用未初始化值）	依赖加载器实现（可能不一致）	部分导出可能为 undefined
典型场景	import './module.js'	require(['module'], callback)	const m = require('./module')

---

总结

• CJS：Node.js 专用，同步加载，需构建工具转换才能在浏览器运行
• AMD：旧浏览器异步加载方案，已被 ESM 取代
• UMD：兼容浏览器 + Node.js 的过渡方案，适合库开发
• ESM：现代标准，支持 Tree Shaking，未来唯一选择

构建工具的作用就是抹平环境差异，让开发者可以用任意模块规范编写代码，最终输出目标环境可运行的版本。