JavaScript 模块系统：CJS/AMD/UMD/ESM

文章目录

前言
[一、CommonJS (CJS) - Node.js 的同步模块系统](#一、CommonJS (CJS) - Node.js 的同步模块系统)
- [1.1 设计背景](#1.1 设计背景)
- [1.2 浏览器兼容性问题](#1.2 浏览器兼容性问题)
- [1.3 Webpack 如何转换 CJS](#1.3 Webpack 如何转换 CJS)
- [1.4 适用场景](#1.4 适用场景)
[二、AMD (Asynchronous Module Definition) - 浏览器异步加载方案](#二、AMD (Asynchronous Module Definition) - 浏览器异步加载方案)
- [2.1 设计背景](#2.1 设计背景)
- [2.2 为什么现代浏览器不原生支持 AMD](#2.2 为什么现代浏览器不原生支持 AMD)
- [2.3 Webpack/Rollup 如何处理 AMD](#2.3 Webpack/Rollup 如何处理 AMD)
- [2.4 适用场景](#2.4 适用场景)
[三、UMD (Universal Module Definition) - 兼容浏览器 + Node.js 的"缝合怪"](#三、UMD (Universal Module Definition) - 兼容浏览器 + Node.js 的"缝合怪")
- [3.1 设计背景](#3.1 设计背景)
- [3.2 为什么 UMD 代码看起来这么"丑"](#3.2 为什么 UMD 代码看起来这么"丑")
- [3.3 构建工具如何生成 UMD](#3.3 构建工具如何生成 UMD)
- [3.4 适用场景](#3.4 适用场景)
[四、ES Modules (ESM) - 现代 JavaScript 标准](#四、ES Modules (ESM) - 现代 JavaScript 标准)
- [4.1 设计背景](#4.1 设计背景)
- [4.2 为什么旧浏览器不支持 ESM](#4.2 为什么旧浏览器不支持 ESM)
- [4.3 构建工具如何处理 ESM](#4.3 构建工具如何处理 ESM)
- [4.4 ESM 模块生命周期的三个阶段](#4.4 ESM 模块生命周期的三个阶段)
- [4.5 适用场景](#4.5 适用场景)
五、模块系统对比总结
总结

前言

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

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

1.1 设计背景

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

1.2 浏览器兼容性问题

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

typescript 复制代码

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

原因：

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

1.3 Webpack 如何转换 CJS

typescript 复制代码

// 原始代码 (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 适用场景

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

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

2.1 设计背景

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

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

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

typescript 复制代码

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

原因：

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

2.3 Webpack/Rollup 如何处理 AMD

typescript 复制代码

// 原始 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 适用场景

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

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

3.1 设计背景

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

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

typescript 复制代码

// 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>

原因：

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

3.3 构建工具如何生成 UMD

bash 复制代码

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

typescript 复制代码

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

关键转换策略：

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

3.4 适用场景

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

javascript 复制代码

export function kInstallScript(src: string): Promise<void> {
  return new Promise((resolve, reject) => {
    const script = document.createElement('script');

    script.src = src;

    script.onload = resolve as () => void;
    script.onerror = reject;

    document.head.append(script);
  });
}

javascript 复制代码

  await kInstallScript(
    kIsMobile
      ? '/lib/mobileFilePreview/file-preview.umd.min.js'
      : '/file-preview/filePreview.umd.min.js'
  );

  kFilePreviewSDK = kIsMobile
    ? (globalThis as any)['file-preview'].FilePreviewSDK
    : (globalThis as any).FilePreview;

// globalThis 在浏览器环境中会将模块挂载到全局对象（如 window）上，属性名就是在打包配置中指定的 name
// UMD 模块的全局变量名

传统浏览器用户：希望通过<script src="awesome-lib.js">直接使用

现代前端工程：希望通过 npm install awesome-lib 引入
用户环境不可控，而 UMD 就是最好的兼容方案

当使用 RollupWebpack 之类的打包器时，UMD 通常用作备用模块

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

4.1 设计背景

目标环境：现代浏览器 + Node.js（ES6+）
核心需求：官方标准、静态分析、Tree Shaking
关键特性：
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

typescript 复制代码

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

原因：

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

4.3 构建工具如何处理 ESM

webpack：

javascript 复制代码

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

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

Vite：

typescript 复制代码

// 开发模式：直接返回 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（无论是否会被执行）

javascript 复制代码

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

构建不可变的依赖图：

(2) 加载阶段（Loading）

浏览器/Node.js 的行为：

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

javascript 复制代码

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

(3) 执行阶段（Evaluation）

严格按拓扑顺序初始化（从叶子节点开始）：

javascript 复制代码

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

模块初始化 ≠ 导出被调用

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

4.5 适用场景

现代前端项目（React/Vue 3+）
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，未来唯一选择

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