第一章：当积木遇上浏览器 — 模块化的前世今生 Chapter 1: When Building Blocks Meet Browsers — The Journey of Modularity

第一章：当积木遇上浏览器 — 模块化的前世今生

从一个令人抓狂的计数器说起

故事要从一个阳光明媚的下午说起。

小明是一个十五岁的高一学生，刚刚开始学习网页开发。他有一个宏伟的计划：为自己喜欢的游戏做一个粉丝网站。在网站的角落里，他想放一个简单的计数器，用来记录自己玩了某个游戏多少个小时。

说干就干，小明打开他的代码编辑器，噼里啪啦敲了起来：

```javascript // counter.js let count = 0;

function increment() { count++; updateDisplay(); }

function decrement() { count--; updateDisplay(); }

function reset() { count = 0; updateDisplay(); }

function updateDisplay() { const display = document.getElementById('counter-display'); display.textContent = count;

// 播放音效 const audio = new Audio('click.mp3'); audio.play();

// 保存到本地存储 localStorage.setItem('gameTime', count); }

function loadSavedTime() { const saved = localStorage.getItem('gameTime'); if (saved) { count = parseInt(saved); updateDisplay(); } }

// 初始化 document.addEventListener('DOMContentLoaded', loadSavedTime); ```

代码运行得很好，小明得意地展示给他的同学看。同学赞不绝口，还问能不能把这个计数器借给他用一下——他想在另一个网站上也放一个类似的东西。

小明满口答应，心想这有什么难的，直接把文件复制过去就行了。

然而，当他真正动手的时候，问题出现了。

首先，这段代码里硬编码了 `localStorage` 的 key 为 `'gameTime'`，如果同学想追踪的是 `'homeworkHours'` 怎么办？其次，音效文件 `'click.mp3'` 的路径也是固定的，一旦文件夹结构不一样就失效了。还有，更糟糕的是，当小明后来想给计数器添加新功能——比如记录日期、分析游玩时间趋势——的时候，他发现自己根本不敢改代码，因为改一处就可能影响另一处，整个文件就像一团纠缠在一起的意大利面。

这可能是每一位前端开发者都经历过的"至暗时刻"。代码量少的时候还好，一旦项目变大，一个文件里塞进几千行代码，改一个变量名都要全局搜索半天，调试一个问题可能引发另一个完全不相干的问题。

小明遇到的不是个例。这种"代码耦合严重、难以复用、牵一发动全身"的痛苦，困扰了前端开发者整整二十年。而它的解决方案，就是我们今天要聊的主题——模块化。

模块化，听起来像是一个程序员才会关心的枯燥技术概念。但如果我告诉你，它其实就像你玩乐高积木的体验，你可能会恍然大悟：每一块积木都是独立的，可以单独使用，也可以和别的积木拼在一起，搭出无限可能的造型。模块化，就是让代码也变成这样的"积木"。

接下来，让我们回到二十多年前，看看人类是如何一步步找到这个"积木魔法"的。

混沌时代：所有代码写在一个文件里的痛苦

要理解模块化的价值，我们得先体会没有模块化的日子有多难熬。

回到互联网的蛮荒时代，大约是2000年前后。那时候的网页还很简陋，大多数网站就是一堆 HTML 文件，每个文件里零星点缀着一些 JavaScript 代码。开发者们习惯把所有的 JavaScript 直接写在 HTML 文件里，用 `<script>` 标签包裹。

随着 Ajax 技术的兴起（对，就是那个让 Gmail 变得神奇的技术），网页开始变得复杂起来。开发者们开始把 JavaScript 代码单独抽出来，放到一个 `.js` 文件里。但问题是，这些文件越来越大——有的项目一个 JavaScript 文件就超过了一万行代码。

想象一下，一本一万页的书，没有目录，没有章节，所有内容从一个字连到另一个字，连段落分隔都没有。你要找一个特定的句子，得从头一页一页翻。这种痛苦，就是当时开发者每天面对的现实。

具体来说，混沌时代有三大灾难：

第一，命名冲突。 假设你在一个文件里定义了一个变量叫 `count`，另一个文件里也定义了 `count`。当浏览器同时加载这两个文件时，第二个 `count` 会覆盖第一个。更糟糕的是，如果你的代码引用了一个叫 `utils` 的函数，但这个函数在其他某个文件里定义，开发者可能根本不知道这个依赖关系，删掉那个文件后代码突然就坏了。

第二，难以追踪依赖。 在混沌时代，代码文件之间的依赖关系完全是隐式的。你可能写了一个 `app.js`，里面调用了 `util.js` 里的函数，但你不知道这个调用关系——没有文档，没有声明，只有运行的时候才发现。"按需发现"式的错误让调试变成了一场噩梦。

第三，无法按需加载。 所有代码必须一次性全部加载。如果你的网站有三个功能，用户只用了一个，他也得下载全部三份代码。这不仅浪费带宽，还会让网页加载变慢，用户体验大打折扣。

当时的开发者尝试用一些约定来缓解问题：比如变量名前加前缀（`myApp_count`）、代码分注释区块（用大量 `/* ========== */` 分隔线）、手动维护一份"我用了谁"的注释文档。但这些都只是补丁，不是解决方案。问题依然存在，而且随着项目变大越来越严重。

文件拼接：早期的"模块化"解决方案

面对混沌时代的痛苦，聪明的开发者们开始想办法。

最早也是最直观的思路是：既然代码写在一个文件里太乱，那就拆成多个文件，然后按顺序拼接起来。

这个想法很简单：把相关的代码放到不同的文件里，比如 `core.js`、`utils.js`、`components.js`、`main.js`，然后用一个构建工具或者简单的脚本把这些文件按正确顺序合并成一个。合并的时候，后面的文件会"看见"前面文件里定义的所有东西。

```javascript // build.js - 一个简单的拼接脚本 const fs = require('fs'); const files = [ 'src/core.js', 'src/utils.js', 'src/components.js', 'src/main.js' ];

const output = files.map(f => fs.readFileSync(f, 'utf8')).join('\n'); fs.writeFileSync('dist/bundle.js', output); ```

这种方法听起来很美好，确实也解决了一些问题：代码文件变小了，每个文件更容易管理；通过调整文件顺序，可以控制全局变量的可见性。

但文件拼接本质上只是"物理拆分"，不是真正的模块化。它有三个根本性的缺陷：

缺陷一：显式声明的缺失。 你怎么知道 `main.js` 依赖 `utils.js`？你得去看代码，或者靠开发者的注释和记忆。没有声明式依赖，文件顺序全靠"魔法数字"维护，一旦顺序出错，整个构建就失败。

缺陷二：全局命名空间依然被污染。 虽然代码被拆开了，但它们仍然共享同一个全局作用域。如果两个文件不小心定义了同名的函数或变量，后果和把它们写在一起没什么区别。

缺陷三：无法按需加载。 所有文件还是要一次性全部加载，然后用某种方式（通常是给 HTML 加很多 `<script>` 标签）按顺序执行。用户必须等待所有代码下载完成才能使用网站。

有人尝试用动态脚本加载来部分解决这个问题：

```javascript // 动态加载脚本 function loadScript(url, callback) { const script = document.createElement('script'); script.src = url; script.onload = callback; document.head.appendChild(script); }

// 按顺序加载 loadScript('core.js', () => { loadScript('utils.js', () => { loadScript('main.js', () => { console.log('全部加载完成'); }); }); }); ```

但这又引入了"回调地狱"——层层嵌套的回调函数让代码变得难以阅读和维护。而且，依赖关系的顺序仍然靠开发者手动保证。

文件拼接就像是把一本书的内容拆成很多章，但不许加目录、不许加页码、必须按固定顺序阅读。这比一本书好一点点，但离真正的"模块化"还差得远。

CommonJS：Node.js带来的模块规范

转机出现在2009年。

那一年，一位名叫 Ryan Dahl 的工程师发布了 Node.js——一个用 JavaScript 编写服务器端程序的运行时。Node.js 带来了一个革命性的想法：JavaScript 不仅可以运行在浏览器里，也可以运行在服务器上。

服务器端的代码有一个天然的优势：文件系统是同步的，你随时可以读取任何文件。这意味着 Node.js 可以实现一个真正的模块系统，而不像浏览器那样受限于网络加载的异步特性。

于是，CommonJS 规范诞生了。

CommonJS 的核心思想非常简单，用两个关键词就能概括：`require` 和 `exports`。

• `require` 用于"引入"一个模块
• `exports` 用于"导出"一个模块的功能

让我用一个例子来展示这个系统有多优雅。假设我们有一个工具模块 `math.js`：

```javascript // math.js function add(a, b) { return a + b; }

function multiply(a, b) { return a * b; }

// 导出函数 exports.add = add; exports.multiply = multiply; ```

然后，在另一个文件 `app.js` 中使用它：

```javascript // app.js const math = require('./math');

console.log(math.add(2, 3)); // 输出: 5 console.log(math.multiply(4, 5)); // 输出: 20 ```

就这么简单！你不需要关心 `math.js` 里还定义了哪些其他东西（它们不会泄露到全局），你只需要知道你需要的那部分。这就是模块化的精髓：清晰的边界，明确的接口。

CommonJS 还解决了依赖追踪的问题。当你在 `app.js` 里写 `require('./math')` 时，Node.js 会自动找出 `math.js` 的位置，加载它，解析它，看看 `math.js` 又依赖什么，然后再加载那些依赖……直到所有依赖都被解析完毕。这个过程叫依赖图解析，它是模块系统的核心能力。

CommonJS 的设计哲学可以总结为三点：

第一，同步加载。 Node.js 的模块加载是同步的，因为服务器文件系统访问很快，且没有网络延迟。这让代码写起来非常直观。

第二，每个文件都是独立的模块作用域。 你在 `math.js` 里定义的 `add` 变量，在 `app.js` 里是看不见的，除非你主动导出它。这彻底解决了全局命名空间污染的问题。

第三，模块是单例的。 无论你在多少个地方 `require('./math')`，内存里只会有一个 `math` 模块的实例。这很合理——你不会希望同一个工具出现两份拷贝。

CommonJS 在 Node.js 生态中大获成功，几乎所有的 Node.js 包都是用它来组织代码的。它简单、直观、解决了核心问题。

但它有一个致命的弱点：它是为服务器端设计的。

在浏览器端，JavaScript 的加载必须通过网络。网络请求是异步的，你不能同步地 `require` 一个模块然后等待它下载完成。如果用 CommonJS 的同步写法，浏览器会"卡住"，用户体验会非常糟糕。

于是，浏览器端的模块化走上了另一条曲折的道路。

AMD与CMD：浏览器端模块化的早期探索

2010年前后，浏览器端的模块化探索进入了群雄逐鹿的时代。CommonJS 虽然在服务器端大放异彩，但浏览器环境需要不同的解决方案。两条主要的技术路线相继登场：AMD 和 CMD。

AMD：异步模块定义

AMD 的全称是 Asynchronous Module Definition，顾名思义，它专门为浏览器端的异步加载而生。

AMD 的代表作品是 RequireJS，由 James Burke 创建。它的核心 API 只有两个：`define` 用于定义模块，`require` 用于加载模块。

```javascript // math.js - 用 AMD 方式定义 define([], function() { function add(a, b) { return a + b; }

function multiply(a, b) { return a * b; }

return { add: add, multiply: multiply }; }); ```

```javascript // app.js - 用 AMD 方式加载 require(['./math'], function(math) { console.log(math.add(2, 3)); // 输出: 5 console.log(math.multiply(4, 5)); // 输出: 20 }); ```

`require(['./math'], callback)` 的第一个参数是依赖数组，第二个参数是回调函数。当所有依赖都加载完成后，回调函数才会被调用。这就是 AMD 的核心：依赖前置，提前执行。

"依赖前置"意味着，在你使用一个模块之前，你必须先在依赖数组里声明它。这让浏览器能够提前分析出所有需要的文件，并行下载它们，然后再执行代码。

CMD：通用模块定义

CMD 是 Sea.js 的实现规范，由玉伯创建。它的设计理念与 AMD 不同：依赖就近，延迟执行。

```javascript // math.js - 用 CMD 方式定义 define(function(require, exports, module) { function add(a, b) { return a + b; }

function multiply(a, b) { return a * b; }

module.exports = { add: add, multiply: multiply }; }); ```

```javascript // app.js - 用 CMD 方式加载 define(function(require, exports, module) { var math = require('./math'); // 依赖就近声明

console.log(math.add(2, 3)); console.log(math.multiply(4, 5));

// 只有执行到这里时，才会真正加载 math.js }); ```

CMD 的特点是，你可以在函数体内的任何位置调用 `require`，模块只有在真正被使用的时候才会加载。这种方式更符合 JavaScript 程序员的直觉，但代价是模块的依赖关系不够直观，需要运行时才能确定。

AMD vs CMD：谁更好？

这个问题在当时引发了不少争论。两者的核心差异可以这样理解：

AMD 像是"先列清单再购物"：先告诉系统你需要什么依赖，系统一次性把东西都准备好，你随时可以使用。

CMD 像是"用的时候再拿"：在需要某个模块的时候才去加载它，但如果你忘记先加载某个依赖，用的时候就会出错。

两种方案各有优劣：

| 特性 | AMD | CMD | |------|-----|-----| | 代表框架 | RequireJS | Sea.js | | 依赖声明 | 提前声明（依赖前置） | 就近声明（延迟执行） | | 执行时机 | 提前执行 | 延迟执行 | | 优点 | 依赖清晰，可并行加载 | 代码更直观 | | 缺点 | 依赖数组稍显冗长 | 依赖关系不够直观 |

最终，这两种方案都没能成为真正的标准。它们是浏览器模块化探索的重要里程碑，为后来的 ES6 模块奠定了基础，但历史最终选择了另一条路。

ES6模块：标准化的曙光

2015年，一个改变 JavaScript 命运的时刻到来了。

ECMAScript 6（简称 ES6，也叫 ES2015）正式发布，这是 JavaScript 语言自诞生以来最大的一次升级。在这次升级中，JavaScript 终于拥有了原生的、官方的模块系统——ES6 Modules，简称 ESM。

ES6 模块的设计融合了前人的智慧：

• 它的语法比 CommonJS 更简洁
• 它支持异步加载，适合浏览器环境
• 它是 ECMAScript 标准的一部分，所有 JavaScript 引擎都要实现它

ES6 模块用两个关键字来完成所有工作：`import` 和 `export`。

基本导出

你可以用 `export` 关键字导出一个模块的功能：

```javascript // math.js export fu