前工程化时代：脚本拼接与模块化萌芽

在2008年的一个潮湿的周二下午，北京中关村某创业公司的办公室里，前端工程师小王正对着屏幕上一串密密麻麻的`<script>`标签头皮发麻。他的任务是修复一个在IE6下偶发性的“`$ is undefined`”错误，而调试过程像一场考古：他必须从50多个按特定顺序加载的脚本中，找出是谁污染了全局的`$`变量，又是谁在错误的时间覆盖了它。这个场景并非孤例，而是那个时代前端开发的常态——一个被称为“脚本拼接（Script Splicing）”的黑暗纪元，一个依赖手动管理、全局命名空间泛滥、构建流程几乎为零的原始时代。今天，当我们习惯于Vite秒级启动、HMR即时反馈的丝滑体验时，回望这段历史，并非仅仅为了怀旧，而是为了理解那些深埋于代码土壤中的根本矛盾：自动化缺失、依赖关系黑盒、以及“配置即代码”的早期尝试如何埋下了变革的种子。本章将带你穿越回前端工程化黎明前的长夜，剖析从“脚本拼接”到“模块化萌芽”的艰难演进，揭示那些早期规范与工具为何最终无法突破其时代局限——缺乏真正的依赖图与静态分析能力——从而为理解Webpack的革命性以及Vite的进化逻辑奠定不可或缺的历史坐标系。

---

一、脚本拼接的黑暗时代：手动管理的“地狱模式”

在2005年Ajax概念兴起之前，前端几乎等同于“网页装饰师”。JavaScript的角色是处理简单的表单验证、轮播图效果，代码量极少，往往直接内嵌在HTML的`<script>`标签里。然而，随着Web 2.0浪潮涌来，Gmail、Google Maps等复杂单页应用（SPA）雏形出现，JavaScript代码量开始爆炸式增长。“一个文件装不下” 成了第一个催生工程化需求的现实问题。解决方案直观而粗暴：分文件存放，然后通过HTML中的多个`<script>`标签手动引入。

1.1 手动排序的“俄罗斯方块”游戏

假设你正在开发一个名为“星际争霸”的Web游戏（2008年最火的游戏之一），其代码结构可能如下：

```html <!-- index.html --> <!DOCTYPE html> <html> <head> <title>星际争霸Web版</title> </head> <body> <!-- 核心库，必须最先加载 --> <script src="libs/jquery-1.4.2.min.js"></script> <script src="libs/underscore-1.1.6.min.js"></script> <script src="libs/backbone-0.5.3.min.js"></script>

<!-- 游戏核心模块，依赖上述库 --> <script src="js/engine/GameEngine.js"></script> <script src="js/engine/Renderer.js"></script>

<!-- 游戏逻辑模块，依赖引擎 --> <script src="js/units/Zergling.js"></script> <script src="js/units/Marine.js"></script>

<!-- 页面初始化，依赖所有游戏模块 --> <script src="js/main.js"></script> </body> </html> ```

表面看，这只是一个文件列表，实则是一场高风险的“俄罗斯方块”。每个`<script>`标签的顺序都精确编码了依赖关系：jQuery必须在Backbone之前，因为Backbone依赖jQuery；游戏引擎必须在具体兵种之前，因为兵种依赖引擎；而`main.js`必须最后执行，因为它要初始化整个游戏。任何顺序的调换——例如不小心将`Zergling.js`放在`GameEngine.js`之前——都会导致`GameEngine is not defined`的运行时错误，且这类错误往往在浏览器控制台中沉默地爆发，难以追踪。

问题的本质在于：依赖关系被隐式地、手动地编码在HTML文件的物理顺序中，而非在代码本身显式声明。这带来了三个致命缺陷：

• **脆弱性**：添加新模块时，开发者必须手动计算其在加载序列中的正确位置，极易出错。
• **不可维护性**：随着模块数量增长（从几十个到上百个），维护这个“加载序列矩阵”成了团队噩梦。新人加入项目，第一周可能都在调试“为什么我的模块不工作？”。
• **无法并行开发**：由于强顺序依赖，模块很难独立开发和测试，必须等待依赖链上游的模块就绪。

1.2 全局命名空间污染：变量的“公共厕所”

更糟糕的是，所有脚本共享同一个全局作用域（在浏览器中是`window`对象）。为了“方便”，开发者常常将工具函数、配置对象直接挂载到全局：

```javascript // utils.js - 一个常见的“便利”做法 var config = { apiUrl: "https://api.example.com", debug: true };

var $ = jQuery; // 再次“方便”地赋值

// game-state.js - 游戏状态管理 var gameState = { players: [], resources: {} }; ```

这种做法的后果是灾难性的：

• **命名冲突**：两个不同的模块可能定义了同名的全局变量（如`config`），后加载的会覆盖先加载的，导致不可预知的行为。著名的“`$`冲突”就是典型案例：如果同时引入了Prototype.js和jQuery，两者都使用`$`，必须调用`jQuery.noConflict()`来“抢回”控制权，这本身就是对全局污染的无奈补救。
• **状态失控**：任何模块都可以在任何地方修改`gameState`，导致数据流变成一锅“意大利面条”，调试时你永远不知道是哪个模块在什么时候篡改了数据。
• **内存泄漏风险**：全局变量永远不会被垃圾回收，直到页面卸载。在长期运行的SPA中，这可能导致内存缓慢增长。

当时流行的“解决方案”是命名空间模式（Namespace Pattern）：人为创建一个全局对象作为“容器”，将所有模块成员挂载其下。

```javascript // 创建全局命名空间 var MyGame = MyGame || {};

// 模块化定义 MyGame.Engine = (function() { var privateVar = "secret";

function init() { /* ... */ }

return { init: init }; })(); ```

这确实缓解了冲突，但引入了新问题： 1. 仍需手动管理加载顺序：`MyGame.Engine`必须在`MyGame.Zergling`之前加载。 2. 冗长的访问路径：`MyGame.Engine.init()`比直接的`init()`多出大量字符。 3. 未解决根本问题：依赖关系依然隐藏在代码逻辑中，而非显式声明。`MyGame.Zergling`内部可能直接调用`MyGame.Engine`，但这种调用关系无法被工具自动分析。

1.3 依赖关系：一张“隐形”的网

让我们用一张图来可视化这种手动管理的依赖网络：

```mermaid graph TD A[index.html] --> B[jquery.js] A --> C[underscore.js] A --> D[backbone.js] A --> E[GameEngine.js] A --> F[Renderer.js] A --> G[Zergling.js] A --> H[Marine.js] A --> I[main.js]

E --> B E --> C E --> D F --> B F --> C F --> D G --> E G --> F H --> E H --> F I --> G I --> H ```

节点是脚本文件，有向边表示“依赖”（A依赖B，则A必须在B之后加载）。这个图完全由开发者在HTML中通过`<script>`标签的物理顺序隐式定义。工具（如浏览器）看到的只是一序列独立的文件请求，无法感知这张网的结构。结果是：

• **无法静态分析**：你无法回答“如果删除`underscore.js`，哪些模块会崩溃？”这个问题，除非手动遍历所有代码。
• **无法优化**：既然不知道依赖关系，就无法进行代码分割（Code Splitting）、按需加载或Tree Shaking（移除未使用代码）。
• **构建黑盒**：任何构建步骤（如压缩、混淆）都只是对整个文件序列的“后处理”，无法根据依赖图进行智能操作。

这种“隐式依赖、手动排序、全局共享”的模式，构成了前工程化时代最核心的痛点。模块化规范的诞生，正是为了从语言和工具层面，将这张隐形的网显式化、自动化。

---

二、模块化规范的萌芽：从“帮派混战”到标准探索

模块化的核心思想朴素而强大：将代码拆分为独立、可复用、自包含的单元（模块），每个模块封装内部实现，仅通过明确定义的接口（API）暴露功能，并清晰声明其依赖的其他模块。这直接回应了脚本拼接时代的三大痛点：封装（解决全局污染）、显式依赖（解决顺序问题）、可组合性（解决维护性）。

然而，模块化之路并非坦途。由于当时JavaScript缺乏语言级模块支持（ES6 Modules直到2015年才定稿），社区探索出了多条路径，形成了著名的“模块化规范三分天下”格局：AMD、CMD与CommonJS。它们代表了不同的设计哲学与适用场景，其争论与融合，本身就是一部微缩的工程史。

2.1 AMD：为浏览器而生的“异步先行者”

AMD（Asynchronous Module Definition，异步模块定义） 规范由James Burke在2009年提出，其核心信条是：浏览器环境必须异步加载模块，以避免阻塞页面渲染。其定义模块的API极其简洁：

```javascript // 定义模块 define('module/name', ['dependency1', 'dependency2'], function(dep1, dep2) { // 模块逻辑 var privateVar = "I'm private";

function publicMethod() { // 使用依赖 dep1, dep2 dep1.doSomething(); }

// 暴露公共API return { publicMethod: publicMethod }; });

// 使用模块 require(['module/name'], function(myModule) { myModule.publicMethod(); }); ```

关键设计决策： 1. 依赖前置（Dependency Pre-declaration）：所有依赖必须在定义时显式列出作为数组参数。这允许加载器（Loader）在执行模块工厂函数之前，并行异步加载所有依赖。 2. 异步加载：通过动态创建`<script>`标签实现，不阻塞浏览器。这是为浏览器量身定做的。 3. 模块ID与路径映射：通过`require.config`配置路径别名，解决模块标识符（如`'module/name'`）到实际URL的映射。

代表实现：RequireJS。它是AMD最著名的实现，成为当时大型Web项目的标配。其工作流程如下图所示：

```mermaid sequenceDiagram participant Main as 主模块 (main.js) participant Loader as RequireJS Loader participant Dep1 as 依赖A (jquery.js) participant Dep2 as 依赖B (underscore.js)

Main->>Loader: require(['A', 'B'], function(A, B) { ... }) Loader->>Loader: 检查A、B是否已加载 alt 未加载 Loader->>Dep1: 动态创建<script>加载A Loader->>Dep2: 动态创建<script>加载B Dep1-->>Loader: 加载完成，执行定义 Dep2-->>Loader: 加载完成，执行定义 end Loader->>Main: 所有依赖就绪，执行回调 ```

优势：

• **真正的异步**：不阻塞页面，用户体验好。
• **依赖显式化**：工具可静态分析依赖数组，生成依赖图。
• **按需加载**：`require` calls可放在代码任意位置，实现懒加载。

劣势：

• **依赖前置的冗长**：对于模块间复杂的依赖网，每个模块的依赖数组可能很长，且容易与工厂函数参数顺序错位。
• **配置复杂性**：路径映射、包（packages）配置、shim（适配非AMD模块）等，使`require.config`变得臃肿。
• **运行时开销**：每个模块被包裹在一个函数中，且加载器本身需要代码，增加了初始负载。

2.2 CMD： Seas.js 的“就近依赖”哲学

CMD（Common Module Definition，通用模块定义） 由国内开发者玉伯（车万翔）在Seas.js中提出，灵感部分来自CommonJS。其核心区别在于：依赖可以就近书写，在需要时再通过`require`获取。

```javascript // CMD模块定义 define(function(require, exports, module) { var $ = require('jquery'); // 依赖在函数内部按需引入

var privateVar = "I'm private";

function publicMethod() { $.ajax(...); }

exports.publicMethod = publicMethod; }); ```

关键设计决策： 1. 依赖就近（Lazy Dependency）：`require` calls写在模块内部，只在执行到该行时才加载依赖。这更符合CommonJS的同步思维，也便于静态分析工具识别依赖（只需扫描`require`字符串）。 2. 统一的模块标识：模块ID与文件路径强关联，简化了路径配置。 3. 暴露接口的灵活性：通过`exports`或`module.exports`，更接近Node.js的CommonJS风格。

代表实现：Seas.js。它在中国社区曾广泛流行，尤其适合对CommonJS语法有习惯的开发者。

与AMD的核心差异对比：

| 特性 | AMD | CMD | |------|-----|-----| | 依赖声明时机 | 前置（定义时数组） | 就近（使用时require） | | 加载时机 | 并行异步加载所有依赖 | 按需同步加载（实际通过异步模拟同步） | | API设计 | `define(id?, deps?, factory)` | `define(factory)`，factory接收`require, exports, module` | | 适用场景 | 浏览器环境，强调异步加载 | 浏览器环境，追求CommonJS语法体验 | | 代表库 | RequireJS | Seas.js |

本质分歧：AMD认为浏览器必须异步，故前置依赖以优化并行加载；CMD认为开发者体验优先，就近书写更自然，加载器内部可处理异步转同步。两者在技术上都通过动态`<script>`注入实现，但依赖识别与加载策略的差异，导致了生态的分裂。

2.3 CommonJS：服务端的“同步之王”与前端的不适配

CommonJS 最初是2009年为服务端JavaScript（如Node.js）设计的模块规范，其哲学是简单、同步、面向服务器：

```javascript // CommonJS模块 (Node.js环境) var fs = require('fs'); // 同步加载 var path = require('path');

function readConfig() { return fs.readFileSync('./config.json', 'utf8'); }

module.exports = { readConfig: readConfig }; ```

核心特征：

• **同步加载**：`require`是同步函数，模块代码执行时，依赖必须已经加载完毕。这在服务器文件I/O场景下可行（文件在本地磁盘，读取快）。
• **模块缓存**：第一次`require`后，模块结果被缓存，后续`require`直接返回缓存，避免重复执行。
• **单次加载**：`require`返回的是`module.exports`的引用，模块只执行一次。

浏览器适配的尝试：Browserify。由于浏览器无法同步读取文件，Browserify采取了构建时打包（Bundling） 策略：在开发/构建阶段，静态分析所有`require`调用，递归解析依赖，将多个模块打包成一个（或少数几个）`<script>`可执行文件。这个文件内部实现了一个简化的模块系统，通过一个模块缓存对象和闭包来模拟CommonJS行为。

```javascript // Browserify打包后的简化示意 var modules = { './mo