一文搞懂AMD、CMD、UMD、ESM和CommonJS

一、模块化的重要性

在前端开发的演进历程中，模块化的出现堪称一场具有里程碑意义的变革。起初，JavaScript 主要负责相对简单的表单验证与简短交互，代码量少，组织形式简单，往往所有代码都写在一个文件里。然而，随着技术的飞速发展，前端能承担的任务愈发繁杂，从复杂的数据处理、页面渲染，再到单页应用（SPA）的构建，代码量呈爆炸式增长。

这时，若依旧将所有代码堆砌在一处，弊端尽显：一方面，全局变量肆意横行，不同功能模块的变量相互干扰，极易引发命名冲突，一个不经意的变量重名，就可能让程序陷入混乱；另一方面，代码的依赖关系错综复杂，维护成本飙升，想要理清模块间的调用顺序、添加或删减功能，都如同在乱麻中摸索，困难重重。

为化解这些难题，模块化应运而生。它如同一位神奇的建筑师，将庞大复杂的代码库拆分成一个个独立且功能单一的模块，每个模块都有自己的专属领地（作用域），对外提供特定的接口，供其他模块按需调用。如此一来，代码的可读性、可维护性与可复用性都得到了质的飞跃，为前端开发的高效推进铺就了坚实道路。而在众多模块化方案中，AMD、CMD、UMD、ESM 和 CommonJS 各放异彩，接下来就让我们深入探究它们的奥秘。

二、CommonJS 规范

2.1 基本概念

CommonJS 诞生之初，旨在为服务器端 JavaScript（尤其是 Node.js）提供一套行之有效的模块化方案。在这个规范里，一个文件即为一个独立的模块，拥有属于自己的 "小天地"------ 独立作用域，这就如同一个个封闭的房间，房间内定义的变量、函数等，对外界是 "隐身" 的，不会干扰到其他模块。

而实现模块间相互通信、协同工作的关键 "桥梁"，便是 module.exports 和 require。module.exports 宛如一扇对外敞开的门，模块内部精心准备的数据、功能等，都通过这扇门暴露给外部；require 则像是一把精准的钥匙，凭借它，其他模块能够轻松打开这扇门，获取所需资源，从而实现模块的复用与组装，构建起庞大复杂的应用体系。

2.2 特点剖析

• 同步加载特性：CommonJS 的加载方式是同步的，这意味着当代码执行到 require 语句时，会如同一个执着的 "寻宝者"，停下手中一切，全心全意等待目标模块加载完成，拿到所需资源后，才肯继续后续征程。这种特性在服务器端环境下，有着得天独厚的优势，因为 Node.js 运行时，模块文件大多存储于本地硬盘，读取速度极快，同步加载的那点短暂等待，几乎可以忽略不计，不会对整体性能造成明显影响。

例如，在一个 Node.js 应用中，有 math.js 模块负责数学运算：

function add(a, b) {
    return a + b;
}
function subtract(a, b) {
    return a - b;
}
module.exports = {
    add: add,
    subtract: subtract
};

在 app.js 中引入并使用：

const math = require('./math');
console.log(math.add(2, 3));  // 输出 5
console.log(math.subtract(1, 2));  // 输出 -1

这里，当执行到 const math = require('./math'); 时，程序会暂停，直至 math.js 模块加载并执行完毕，才接着执行后续的打印操作。

• 代码运行在模块作用域：模块内部的代码就像在一个与世隔绝的 "世外桃源"，拥有独立的作用域，不用担心变量、函数名与其他模块冲突。每个模块都是一座孤岛，彼此的数据和逻辑互不干扰，极大地提升了代码的稳定性与可维护性。

假设存在两个模块 moduleA.js 和 moduleB.js：

// moduleA.js
const name = 'Module A';
function greet() {
    console.log('Hello from ' + name);
}
module.exports = {
    name: name,
    greet: greet
};
// moduleB.js
const moduleA = require('./moduleA');
console.log(moduleA.name);
moduleA.greet();

在 moduleB.js 中，即便它引入了 moduleA.js，但 moduleA.js 里的 name 和 greet 函数，在 moduleB.js 的作用域中是无法直接访问的，只能通过 moduleA 对象调用，有效避免了命名冲突。

• 模块加载缓存机制：模块首次加载时，就如同被盖上了一个独特的 "记忆印章"，系统会将其运行结果缓存起来。后续若再次遇到相同的 require 请求，直接返回缓存中的结果，无需重复加载执行，大大节省了资源开销。

比如有一个 counter.js 模块：

let count = 0;
function increment() {
    count++;
    return count;
}
module.exports = {
    increment: increment
};

在 app.js 中多次引入：

const counter1 = require('./counter');
const counter2 = require('./counter');
console.log(counter1.increment());  // 输出 1
console.log(counter2.increment());  // 输出 2

可以看到，尽管 counter.js 被 require 了两次，但实际上其代码只在首次加载时执行了一次，后续调用 increment 函数时，操作的是同一份缓存中的 count 变量。

• module.exports 输出值拷贝：module.exports 输出的是值的拷贝，这意味着一旦模块对外输出某个值，模块内部即便对该值进行修改，也不会影响到外部获取到的拷贝版本。

以 config.js 模块为例：

const config = {
    port: 3000,
    databaseUrl: 'mongodb://localhost:27017/mydb'
};
module.exports = config;

在 app.js 中使用：

const appConfig = require('./config');
console.log(appConfig.port);  // 输出 3000
// 假设在 app.js 中修改端口号
appConfig.port = 3001;
// 再次引入 config.js 模块
const anotherConfig = require('./config');
console.log(anotherConfig.port);  // 依然输出 3000

这里，虽然在 app.js 中修改了 appConfig 的 port 值，但再次引入 config.js 时，获取到的 port 还是最初的 3000，因为 require 返回的是 config 对象的拷贝，模块内部的变化不会渗透到外部。

三、AMD 规范

3.1 简介

AMD，全称为 Asynchronous Module Definition，即异步模块定义，专为浏览器端复杂的模块加载场景量身打造。在浏览器环境中，页面加载效率至关重要，若像传统方式那样同步加载 JavaScript 文件，一旦文件数量增多、体积增大，极易造成浏览器长时间阻塞，页面出现 "假死"，用户体验极差。

AMD 规范应运而生，其核心实现依托于 RequireJS 库。它巧妙地解决了浏览器异步加载模块的难题，允许模块并行加载，让浏览器在等待模块加载的过程中，不至于 "无所事事"，还能继续处理其他任务，极大地提升了页面的响应速度与加载效率，为构建大型复杂的前端应用提供了有力支撑。

3.2 依赖前置原则

AMD 规范一大显著特点便是依赖前置。这意味着在定义模块之际，就必须清晰、明确地声明该模块所依赖的其他模块，就像出发前先规划好路线、准备好行囊一样。

例如，我们定义一个名为 userModule 的模块，它依赖于 dataService 模块和 uiUtils 模块：

define('userModule', ['dataService', 'uiUtils'], function (dataService, uiUtils) {
    function displayUserInfo() {
        const userData = dataService.fetchUserData();
        uiUtils.showMessage(userData.username);
    }
    return {
        displayUserInfo: displayUserInfo
    };
});

在这段代码中，define 函数的第一个参数 'userModule' 明确了模块名称，第二个参数 ['dataService', 'uiUtils'] 则将依赖模块一一列出，这些依赖模块会依照顺序作为参数传入第三个参数 ------ 工厂函数中。如此一来，在模块代码执行前，AMD 加载器便知晓要提前去获取哪些依赖，待所有依赖模块加载完毕，工厂函数才正式启动，执行模块内部逻辑，确保模块运行时所需资源已全部就位。

再看如何使用 RequireJS 加载并使用这些模块。首先，在 HTML 文件中引入 RequireJS 库：

<script src="require.js" data-main="main.js"></script>

这里的 data-main 属性指定了应用的主入口模块 main.js。在 main.js 中，我们可以这样配置和使用模块：

require.config({
    baseUrl: 'js/',
    paths: {
        'dataService': 'services/dataService',
        'uiUtils': 'utils/uiUtils',
        'userModule': 'modules/userModule'
    }
});
require(['userModule'], function (userModule) {
    userModule.displayUserInfo();
});

require.config 用于配置模块路径，确保加载器能精准找到各个模块文件。随后的 require 函数则根据需求加载 userModule，并在其依赖的 dataService 和 uiUtils 模块都加载成功后，执行回调函数，调用 userModule 的 displayUserInfo 方法，展示用户信息。通过这种方式，AMD 规范让模块加载有条不紊，即使面对复杂的模块依赖关系，也能高效运行，为浏览器端的模块化开发开辟了便捷之路。

四、CMD 规范

4.1 概述

CMD，即 Common Module Definition，通用模块定义，它扎根于国内前端开发土壤，依托 SeaJS 茁壮成长，同样致力于解决浏览器端 JavaScript 模块化难题。与 AMD 相比，CMD 别具一格，采用就近依赖原则，如同一位灵动的舞者，在代码的舞台上轻盈跳跃，将模块依赖的声明与使用时机把控得恰到好处，使代码的书写与组织更加灵活、优雅，极大提升了代码的可维护性与可读性，为前端开发人员赋予了更多创作的自由。

4.2 就近依赖优势

CMD 规范最大的亮点当属就近依赖。在 CMD 构建的代码世界里，模块无需像 AMD 那样，在定义之初就将所有依赖前置罗列，而是宛如一位从容不迫的旅人，在漫漫旅途中，当行至需要某个模块助力的关键路口，才通过 require 函数精准召唤它现身。

这种方式带来诸多益处，一方面，避免了过早加载不必要的模块，减少资源浪费，提升页面加载的初始速度，尤其在处理复杂页面、多模块协同工作时，效果显著。例如，在一个电商页面中，商品展示模块、购物车模块、用户评论模块等各司其职，若采用 CMD 规范，用户浏览商品详情时，只需加载商品展示相关模块及其依赖，无需提前唤醒购物车、评论等模块，待用户点击对应功能按钮时，再按需加载，让页面始终保持轻盈高效的运行姿态。

另一方面，就近依赖使得代码逻辑更加贴合人类的思维习惯，模块间的耦合度进一步降低，开发者能更聚焦于当下功能的实现，当需求变更或模块升级时，改动范围小，维护成本大幅降低，为项目的迭代演进保驾护航。

五、UMD 规范

5.1 通用模块定义

UMD，全称为 Universal Module Definition，即通用模块定义，恰似一位集大成者，横空出世于前端模块化的江湖。彼时，CommonJS 在服务器端稳占一席之地，AMD 与 CMD 在浏览器端各领风骚，可一旦涉及跨平台开发，不同模块规范之间的差异就如同横亘在开发者面前的一道道沟壑，代码难以无缝衔接。

UMD 规范应运而生，它凭借一套巧妙的判断逻辑，将 CommonJS、AMD、CMD 等规范的精髓融会贯通。犹如拥有一个智能 "大脑"，在模块加载之际，先对运行环境进行精准 "探测"：若身处 Node.js 环境，便遵循 CommonJS 规范，通过 module.exports 导出模块；若发现是支持 AMD 的浏览器环境，就依循 AMD 规范，使用 define 函数异步加载模块；倘若处于既不支持 CommonJS 也不支持 AMD 的普通浏览器环境，还能将模块挂载到全局对象（如 window）上，以全局变量的形式供外界访问。如此一来，同一套代码，既能在浏览器中与用户 "亲密互动"，又能在服务器端高效处理数据，甚至在移动端 APP 里也能游刃有余，真正实现了 "一次编写，到处运行" 的宏伟愿景，为前端开发者铺就了一条通往跨平台开发的康庄大道。

5.2 实现原理示例

以广为人知的 JQuery 库为例，其早期版本巧妙运用 UMD 规范，使得自身能在多种环境中大放异彩。剖析其源码，核心逻辑大致如下：

(function (global, factory) {
    if (typeof exports === 'object' && typeof module!== undefined) {
        // 若处于 CommonJS 环境，如 Node.js
        module.exports = factory(require('jquery'));
    } else if (typeof define === 'function' && define.amd) {
        // 若处于 AMD 环境，如使用 RequireJS 的浏览器
        define('toggler', ['jquery', factory]);
    } else {
        // 其他普通浏览器环境，挂载到全局对象 window 上
        global.toggler = factory(global, factory);
    }
})(this, function ($) {
    function init() {}
    return {
        init: init
    };
});

在这段代码中，首先映入眼帘的是外层的立即执行函数（IIFE），它宛如一个神秘的 "魔法结界"，将内部代码包裹其中，隔绝外界干扰，同时接收两个关键参数：global 代表全局对象（在浏览器环境下通常是 window，在 Node.js 环境下则是 global），factory 是工厂函数，承载着模块的核心逻辑与功能实现，肩负着创建并返回模块实例的重任。

进入函数内部，首先进行一轮 "环境侦探"：通过 typeof exports === 'object' && typeof module!== undefined 判断是否身处 CommonJS 环境，若条件成立，意味着处于 Node.js 之类的环境，此时便果断调用 module.exports = factory(require('jquery'))，借助 require 引入依赖的 jquery 模块，再将工厂函数 factory 的执行结果通过 module.exports 导出，完美契合 CommonJS 规范的模块导出机制。

紧接着，typeof define === 'function' && define.amd 条件登场，它如同敏锐的 "雷达"，探测是否处于 AMD 环境。一旦命中，意味着当前是在支持 AMD 的浏览器环境中，像使用 RequireJS 加载模块的场景。此时，define('toggler', ['jquery', factory]) 语句迅速启动，将模块命名为 toggler，并将依赖的 jquery 模块以及工厂函数 factory 列入依赖数组，遵循 AMD 规范的依赖前置与异步加载原则，确保模块及其依赖能高效、有序地加载与执行。

倘若前面两个条件都不满足，说明处于既不支持 CommonJS 也不支持 AMD 的普通浏览器环境，代码果断执行 global.toggler = factory(global, factory)，将工厂函数 factory 的执行结果挂载到全局对象 global（即 window）上，以 toggler 为全局变量名供外部代码访问，这种兜底策略使得模块在简单的浏览器环境中也能正常运行，不被环境所限。

而工厂函数内部，function init() {} 与 return { init: init }; 定义了模块对外暴露的初始化方法 init，外部代码获取到模块实例后，便可调用此方法开启相应功能，实现模块的价值。通过这样一套严谨且精妙的环境判断与适配机制，JQuery 成功借助 UMD 规范挣脱了环境的枷锁，在不同平台、不同场景下都能为开发者提供稳定、高效的服务，成为前端开发领域的中流砥柱，也为众多库与框架的跨平台实践树立了光辉典范。

六、ESM 规范

6.1 JavaScript 官方模块化

ESM，即 ECMAScript Modules，作为 JavaScript 官方钦定的模块化标准，自诞生之日起便备受瞩目。它承载着诸多开发者对 JavaScript 模块化的美好期许，致力于统一不同环境下的模块管理，让代码在浏览器与 Node.js 等多种平台间畅行无阻。

如今，现代浏览器对 ESM 的支持愈发成熟，从 Chrome、Firefox 到 Safari 等主流浏览器，只需在 script 标签上轻轻添上 type="module" 属性，便可无缝开启 ESM 之旅，轻松加载并执行模块代码。在 Node.js 环境中，自版本 13.2 起，通过在 package.json 中指定 "type": "module"，同样能让 ESM 一展身手，与 CommonJS 规范和谐共处，为后端开发注入新的活力。这种跨平台的广泛支持，使得 ESM 成为当下 JavaScript 模块化开发的中流砥柱，引领着代码组织与复用的新潮流。

例如，在一个现代浏览器项目中，创建 main.js 作为入口文件：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ESM Example</title>
</head>
<body>
    <script type="module" src="main.js"></script>
</body>
</html>

在 main.js 中，我们可以尽情使用 ESM 的导入导出语法：

import { add } from './math.js';
console.log(add(2, 3));

对应的 math.js 模块：

export function add(a, b) {
    return a + b;
}

这里，浏览器能顺利识别 type="module"，按照 ESM 规范加载并执行模块，展示出强大的模块化能力。在 Node.js 端，若有一个包含 main.js 和 math.js 的项目，配置好 package.json 中的 "type": "module" 后，同样的代码结构也能完美运行，实现了浏览器与服务器端代码模块化的统一，大大降低了开发的复杂性，提升了代码的可维护性与复用性。

6.2 特性解析

ESM 的设计理念独具匠心，核心在于静态化，力求在编译阶段就将模块的依赖关系与输入输出变量确定得明明白白。这与 CommonJS 等传统规范形成鲜明对比，后者往往在运行时才能确定这些关键信息。

在 ESM 构建的模块世界里，import 和 export 语句宛如精密的齿轮，紧密咬合，协同工作。export 精准定义模块对外提供的接口，哪些变量、函数、类可以被外部访问，一目了然；import 则依据这些接口，将所需模块的功能引入当前模块，而且导入的变量皆为只读，避免了不经意间的修改，保障了模块的稳定性。

例如，有 user.js 模块：

export const name = 'John Doe';
export function greet() {
    console.log(`Hello, ${name}!`);
}

在 app.js 中使用：

import { name, greet } from './user.js';
console.log(name);
greet();

在编译阶段，JavaScript 引擎便能依据 import 和 export 语句，提前知晓模块间的依赖关系，进行一系列优化，如预加载、并行加载模块，显著提升运行效率。同时，静态化使得静态分析工具大显身手，精准的类型检查、智能的自动补全纷至沓来，让代码错误无处遁形，开发者得以在编译时就将问题扼杀在摇篮之中，极大提升了代码质量与开发效率，为 JavaScript 大型项目的开发与维护保驾护航。

七、对比总结

7.1 差异对比

为了更清晰地呈现这五种模块化规范的特点，下面以表格形式从加载方式、依赖处理、适用场景等维度进行对比：

规范	加载方式	依赖处理	适用场景	示例语法
CommonJS	同步加载	运行时确定，使用 require 同步获取模块	主要用于 Node.js 服务器端开发，模块文件存储在本地硬盘，同步加载开销小	const module = require('./module');module.exports = value;
AMD	异步加载	依赖前置，定义模块时声明依赖，加载完成后执行回调	适用于浏览器前端开发，解决页面加载阻塞问题，提升用户体验	define('module', ['dep1', 'dep2'], function(dep1, dep2) {});require(['module'], function(module) {});
CMD	异步加载	就近依赖，使用时按需加载依赖模块	浏览器前端开发，优化资源加载顺序，代码编写灵活，降低耦合度	define(function(require, exports, module) { const mod = require('./mod');});
UMD	先判断环境，按需采用同步（CommonJS）或异步（AMD）加载，或挂载全局变量	根据环境判断，融合 CommonJS 和 AMD 特点	适用于跨平台开发，需要在浏览器、Node.js 等多种环境通用的库或框架	见前文 JQuery 示例代码，包含对 CommonJS、AMD 和全局变量挂载的判断逻辑
ESM	静态加载，编译阶段确定依赖	静态导入导出，import 和 export 语句明确模块依赖与接口，导入变量只读	现代浏览器和 Node.js 环境均支持，是 JavaScript 模块化的未来趋势，适用于新项目开发，便于静态分析与优化	import { value } from './module';export const value = 1;

7.2 应用场景建议

在实际项目开发中，如何选择合适的模块化规范呢？以下是一些基于不同项目类型的建议：

若你正在开发 Node.js 后端应用，CommonJS 无疑是首选。它与 Node.js 的运行机制完美契合，模块同步加载的特性不会成为性能瓶颈，开发过程简洁高效，大量成熟的 Node.js 模块都基于此规范构建，能轻松复用社区资源，加快项目推进。

对于传统的浏览器前端项目，若需兼容老旧浏览器（不支持 ESM），AMD 或 CMD 可派上用场。AMD 适合构建大型复杂应用，依赖前置确保模块加载顺序可控，搭配 RequireJS 能有效管理模块加载，提升页面加载效率；CMD 则更注重开发灵活性，就近依赖使代码逻辑清晰，SeaJS 作为其配套工具，能为项目带来便捷的模块化开发体验。不过，随着现代浏览器对 ESM 支持日益完善，新项目优先考虑 ESM 会是明智之举，它兼具简洁语法与高效性能，配合打包工具，能轻松应对复杂前端架构。

而在开发跨端应用（如 Electron、React Native 等）或通用 JavaScript 库时，UMD 便能大显身手。它能自适应不同环境，一套代码多处运行，为开发者免去环境适配的烦恼，让代码在浏览器、服务器、移动端等平台畅行无阻，极大提升代码复用性与项目的可维护性。

总之，了解并掌握这五种模块化规范，能让我们在面对不同开发场景时，精准选择最适配的工具，编写出结构清晰、易于维护的高质量代码，为项目的成功落地奠定坚实基础。