第1章：前端开发的“蛮荒时代”与工程化萌芽

2008年的一个雨夜，小李盯着屏幕上密密麻麻的`<script>`标签，额头渗出细密的汗珠。他刚刚在团队协作平台上收到一条紧急消息：“用户登录模块崩溃了！所有用户无法访问！” 经过两小时排查，罪魁祸首竟是一个再简单不过的原因：他更新了jQuery库的版本，却忘了调整另一个插件脚本的引入顺序——因为那个插件依赖旧版jQuery的某个已被移除的API。这个看似低级失误的背后，是一个时代的前端开发缩影：没有构建工具，没有模块系统，没有自动化流程，每个`<script>`标签都像一颗不定时炸弹，而开发者们则在炸弹阵中跳着致命的舞蹈。

这不是危言耸听。在Webpack、Vite等现代构建工具出现之前，前端开发长期处于一种“蛮荒状态”。代码如原始部落般散落在各处，依赖关系靠开发者心智模型维护，版本冲突靠运气规避，性能优化靠手动拼凑。JavaScript从一种“网页小助手”语言，演变为驱动复杂单页应用（SPA）的核心引擎，但它的开发方式却几乎停滞在石器时代。当后端工程师早已用上Maven、Gradle管理依赖、自动化构建时，前端开发者仍沉浸在`<script src="...">`的迷宫中，靠复制粘贴和祈祷来维系脆弱的系统。

这种混乱并非开发者懒惰或能力不足，而是技术演进中的必然阶段。jQuery的流行让DOM操作变得简单，Backbone、AngularJS等框架催生了单页应用萌芽，但工具链的演进始终滞后于应用复杂度的爆炸。模块化、依赖管理、代码分割、资源优化——这些如今被视为理所当然的概念，在当年都是亟待解决的“痛点”。正是这些痛点的集中爆发，催生了前端工程化的萌芽，最终引出了Webpack、Rollup、Vite这一系列构建工具的进化之路。

本章将带你穿越回那个“手动档”时代，通过一个真实感十足的案例——“没有构建工具的项目”——直观感受工程化前的开发日常。我们将看到，当项目规模从几个文件扩散到数百个，当团队从单人作战扩展到十人以上，当用户体验要求从“能用”提升到“流畅”，那些曾经被忽视的小问题如何演变成吞噬项目进度的巨兽。这不是怀旧，而是理解“为什么需要工程化”的必修课。只有看清来时的路，才能真正明白我们为何要迁徙，以及迁徙向何方。

---

脚本标签的迷宫：早期前端的“手动档”困境

想象一下2005年的一个典型Web项目结构：

``` /my-website ├── index.html ├── about.html ├── contact.html ├── js/ │ ├── jquery-1.3.2.min.js │ ├── jquery-ui-1.7.2.custom.min.js │ ├── prototype.js │ ├── scriptaculous.js │ ├── main.js │ ├── navigation.js │ ├── form-validation.js │ └── analytics.js ├── css/ │ ├── style.css │ └── theme.css └── images/ ```

打开`index.html`，你会看到这样的“经典布局”：

```html <!DOCTYPE html> <html> <head> <title>我的网站</title> <link rel="stylesheet" href="css/style.css"> <link rel="stylesheet" href="css/theme.css"> </head> <body> <!-- 页面内容 -->

<!-- 脚本地狱开始 --> <script src="js/prototype.js"></script> <script src="js/scriptaculous.js"></script> <script src="js/jquery-1.3.2.min.js"></script> <script src="js/jquery-ui-1.7.2.custom.min.js"></script> <script src="js/navigation.js"></script> <script src="js/form-validation.js"></script> <script src="js/analytics.js"></script> <script src="js/main.js"></script> </body> </html> ```

表面上看，这只是一个普通的HTML文件。但在这看似简单的`<script>`标签序列中，隐藏着前端开发最初的“原罪”：

1.1 顺序依赖：脆弱的“多米诺骨牌”

JavaScript的加载和执行是同步且阻塞的。浏览器按照`<script>`标签在HTML中出现的顺序依次下载并执行脚本。这意味着，如果`navigation.js`依赖jQuery，而jQuery又在`main.js`之后引入，那么当`navigation.js`执行时，`$`符号根本不存在——整个页面瞬间崩溃。

这种顺序依赖带来了几个致命问题：

• **隐式契约**：脚本间的依赖关系没有显式声明，完全依赖开发者记住“A必须在B之前加载”。新成员接手项目时，常因不了解这个隐式顺序而引入bug。
• **版本耦合**：如果jQuery升级到1.4版本，而`form-validation.js`只兼容1.3，那么即使顺序正确，也可能因API变更而失效。此时你需要：

1. 找到所有依赖旧版jQuery的脚本 2. 逐个检查兼容性 3. 要么降级jQuery，要么重写插件 这个过程在几十个脚本的项目中如同噩梦。

• **跨页面维护**：如果网站有10个页面，每个页面都需要相同的脚本，那么每次增删脚本，你都需要修改10个HTML文件。更可怕的是，如果某个页面需要额外的脚本（比如`contact.html`需要表单验证），你就得在10个文件中分别调整顺序——这种重复劳动不仅低效，而且极易出错。

真实案例：2009年，一个中型电商网站有12个主要页面。市场部门要求添加一个新的用户行为分析脚本。前端工程师小王需要在12个HTML文件的特定位置插入`<script src="analytics.js"></script>`。他仔细检查了依赖关系：analytics脚本需要jQuery，但不能与另一个A/B测试脚本冲突。最终，他在8个页面中成功添加，却因在“产品详情页”中顺序错误，导致该页面30%的用户无法将商品加入购物车——因为analytics脚本提前执行，覆盖了购物车对象的某个关键方法。修复花费了整整一天，而问题根源仅仅是一个脚本标签的位置错误。

1.2 全局命名空间污染：所有变量都是“公共财产”

在没有模块系统的时代，JavaScript只有一个全局作用域——`window`对象。所有变量、函数、类都自动成为全局变量：

```javascript // navigation.js var currentPage = 'home'; function initMenu() { /* ... */ }

// form-validation.js var currentPage = 'contact'; // 灾难！覆盖了navigation.js的变量 function initMenu() { /* ... */ } // 再次灾难！函数被覆盖 ```

这种“全局共享”策略带来了几个经典问题：

• **命名冲突**：两个脚本不小心使用了相同的变量名或函数名，后加载的会覆盖先加载的。这种bug极难追踪，因为冲突可能发生在任何两个脚本之间，且症状常常是“某个功能突然失效”，而非直接报错。
• **依赖隐式传递**：`main.js`可能依赖`navigation.js`中定义的`currentPage`变量，但没有任何声明。如果某天`navigation.js`重构，移除了这个变量，`main.js`就会在运行时神秘失效。
• **测试困难**：无法隔离测试单个模块，因为每个模块都隐式依赖全局环境。

行业笑话：当时前端社区流传着一个“最佳实践”——给所有变量加上前缀，比如`nav_currentPage`、`form_currentPage`。这就像在公共厕所隔间上贴满“此隔间有人”的纸条，虽然暂时避免了冲突，但让代码变得冗长丑陋，且治标不治本。

1.3 依赖管理：手工的“版本地狱”

当项目使用多个第三方库时，依赖管理成为一场灾难：

• **手动下载与更新**：没有npm，每个库都需要手动从官网下载JS/CSS文件，放入项目目录。更新版本时，需要重新下载、替换、测试。团队协作时，A下载了jQuery 1.9，B下载了1.10，导致“在我机器上能运行”的经典问题。
• **依赖传递缺失**：如果库A依赖库B的v1.2，而库C依赖库B的v1.5，你只能选择一个版本，另一个库必然出问题。没有工具能自动分析并解决这种冲突。
• **文件冗余**：不同页面可能需要不同子集的库，但为了简单，开发者往往在每个页面引入所有脚本，导致用户下载了大量无用代码。

数据佐证：根据2009年《JavaScript库使用调查报告》（基于对500个网站的爬取分析），平均每个页面包含14.7个外部JavaScript文件，其中3.2个是重复引入的（同一库的不同版本或功能重叠的库）。这种“脚本肥胖症”直接导致页面加载时间中位数达到8.2秒（在当时的ADSL环境下）。

1.4 性能优化：手动的“微积分”

在HTTP/1.1时代，浏览器对同一域名的并发请求数有限制（通常6个），过多的脚本文件会导致排队阻塞。开发者不得不手动优化：

• **手动合并**：用各种在线工具或自己写脚本将多个JS文件合并为1-2个，但合并后调试困难（source map尚未普及）。
• **手动压缩**：使用YUI Compressor等工具手动压缩，每次修改都要重新压缩，极易忘记。
• **手动放置**：将脚本放在`<body>`底部以减少阻塞，但某些脚本（如必须在DOM加载前运行的polyfill）又需放在`<head>`，平衡点全靠经验。
• **缓存策略手工配置**：通过修改文件名（如`script.v1.js`）实现缓存失效，但版本号需要手动维护，且容易遗漏。

这些优化不仅繁琐，而且每次发布都像一次高风险手术：合并错了顺序？功能全废。压缩时出错了？用户看到乱码。忘记更新版本号？用户 stuck在旧版本。

1.5 团队协作：代码合并的“修罗场”

当多人协作时，问题进一步放大：

• **文件结构混乱**：没有约定，有人把JS放在根目录`/js`，有人按功能分目录`/js/utils`、`/js/components`，新成员找不到文件。
• **命名无规范**：`nav.js`、`navigation.js`、`menu.js`可能实现相同功能，导致重复代码。
• **合并冲突频发**：多人修改同一个JS文件时，由于没有模块封装，冲突往往涉及大段代码，解决起来如同拼图。
• **环境配置不一致**：开发者本地可能使用不同版本的库，导致“在我机器上没问题”。

真实录音（2009年某团队会议记录）： > 甲：“我昨天改了`main.js`，但今天测试发现导航栏不工作了。” > 乙：“我也改了`main.js`，加了个新功能。你改哪里了？” > 甲：“我在第45行加了analytics代码。” > 乙：“糟糕，我第40-60行重写了菜单逻辑，覆盖了你的代码。我马上重发文件给你。” > 甲：“等等，我这边也改了其他文件... 我们最好今晚早点碰头，把所有修改合并一次。”

这种“文件级”的协作模式，在模块化时代是不可想象的。它迫使得团队花费大量时间在协调而非创造上。

---

库的黎明：jQuery 与 Backbone 的救赎与陷阱

2006年，jQuery 1.0 发布，它用简洁的API（`$()`选择器、链式调用）解决了浏览器兼容性噩梦，瞬间风靡。开发者欢呼：“终于不用再写`if (document.all) ... else if (document.getElementById) ...`了！” jQuery 像一把瑞士军刀，统一了DOM操作、事件处理、动画效果，显著降低了直接操作DOM的复杂度。

但jQuery并未解决根本的代码组织问题。它更像一个增强的工具集，而非架构框架。使用jQuery的项目，代码往往变成这样：

```javascript // main.js - 所有逻辑堆积在此 $(document).ready(function() { // 导航栏逻辑 $('#menu li').click(function() { ... });

// 表单验证 $('#contact-form').submit(function() { ... });

// 轮播图 initCarousel();

// 数据分析 trackPageView();

// ... 还有50行其他代码 }); ```

jQuery时代的典型项目结构： ``` /js ├── jquery.min.js ├── jquery-ui.min.js ├── main.js # 上帝对象：包含所有页面逻辑 ├── homepage.js # 仅 homepage 用，但也被 main.js 引入 ├── product.js # 仅 product 页用 └── utils.js # 工具函数，被 everywhere 引用 ```

问题显而易见：

• **逻辑耦合**：`main.js` 变成“上帝脚本”，任何修改都可能影响其他功能。
• **页面特异性差**：`homepage.js` 在非首页也被加载，浪费带宽。
• **难以测试**：无法单独测试“表单验证”逻辑，因为它和导航栏代码混在一起。

2.1 Backbone.js：MVC 的启蒙与未竟之业

2010年，Backbone.js 横空出世，它带来了模型-视图-控制器（MVC） 的分离思想：

```javascript // 使用 Backbone 的组织方式 var Task = Backbone.Model.extend({ ... }); var TaskList = Backbone.Collection.extend({ ... }); var TaskView = Backbone.View.extend({ ... }); ```

这似乎指明了方向：按功能模块组织代码。一个任务管理应用可以清晰地分为`models/`、`views/`、`collections/`目录。

但Backbone刻意保持轻量，它不提供模块加载器、不规定文件结构、不处理依赖。开发者可以自由选择RequireJS、CommonJS，或继续用`<script>`标签。结果是：理念先进，实践混乱。

一个典型的Backbone项目可能长这样：

```html <!-- index.html --> <script src="lib/jquery.js"></script> <script src="lib/underscore.js"></script> <script src="lib/backbone.js"></script>

<!-- 按功能分组，但依赖顺序仍需手动维护 --> <script src="models/task.js"></script> <script src="models/project.js"></script> <!-- 依赖 task.js --> <script src="collections/tasks.js"></script> <!-- 依赖 task.js, backbone.js --> <script src="views/task-view.js"></script> <!-- 依赖 task.js, collections/tasks.js --> <script src="views/app-view.js"></script> <!-- 依赖所有 above -->

<script src="router.js"></script> <script src="main.js"></script> ```

尽管按功能划分了文件，但脚本顺序的诅咒依然存在。`views/task-view.js` 依赖 `models/task.js`，所以前者必须放在后者之后。随着文件数量增长（一个中型Backbone应用可能有50+个JS文件），维护这个顺序变成了一场灾难。新增一个文件，你需要： 1. 确定它依赖哪些已有模块 2. 找到这些模块在HTML中的位置 3. 将新文件插入到所有依赖之后、被依赖之前

开发者吐槽（来自2012年Stack Overflow）： > “我昨天加了一个`CommentView`，它依赖`CommentModel`和`UserCollection`。我花了20分钟才找到`CommentModel`在HTML里的位置，然后发现`UserCollection`又依赖`UserModel`... 最后我干脆把新脚本放在所有文件后面，结果因为`router.js`需要`CommentView`，整个应用启动失败。我今天的主要工作不是写功能，而是排脚本顺序。”

2.2 AMD 与 CMD：模块化规范的“战国时代”

模块化需求如此迫切，社区开始探索解决方案。两大规范应运而生：

• **AMD（Asynchronous Module Definition）**：以RequireJS为代表，强调**异步加载**，适合浏览器环境。

```javascript // 定义模块 define(['jquery', 'underscore'], function($, _) { return { doSomething: function() { ... } }; });

// 加载模块 require(['app/main'], function(main) { main.init(); }); ```

• **CMD（Common Module Definition）**：以SeaJS为代表，受Node.js的Comm