前端工程化的诞生：为什么我们需要构建工具

如果你是初学前端，你一定用过 `<script>` 标签——把 JavaScript 文件引入 HTML，浏览器就能直接执行。在很长一段时间里，这就是前端开发的全部。当我们想用 jQuery，就在 HTML 里加一行 `<script src="jquery.js"></script>`；想再加一个工具库，再加一行 `<script src="underscore.js"></script>`。看起来简单、自然、不需要任何"构建"。

但当你真正开始做一个稍微复杂一点的项目时，你会发现这种"原始"的开发方式，会以各种意想不到的方式让你难受——代码莫名其妙报错、变量被覆盖、新同事接手项目时一脸茫然、上线后页面加载慢得令人抓狂。

这一章，我们将从一段"看似能跑"的代码出发，亲手复现这些问题，看清前端工程化要解决什么，再回顾构建工具十年来的演进，最后完成你的第一个 npm 初始化项目，为后续章节打下基础。

1.1 一个真实的多文件 jQuery 项目

让我们回到 2012 年前后。那时候 jQuery 几乎是前端开发的标配，前端代码的组织方式非常朴素：把不同的功能拆成不同的 JavaScript 文件，然后按顺序用 `<script>` 标签加载。假设我们要做一个简单的"用户管理"页面，可能会有这样的文件结构：

``` user-admin/ ├── index.html ├── js/ │ ├── lib/ │ │ ├── jquery.js │ │ └── underscore.js │ ├── utils/ │ │ └── dom.js │ ├── models/ │ │ └── User.js │ ├── views/ │ │ └── UserView.js │ └── app.js └── css/ └── style.css ```

这是一个相当"标准"的项目结构。每个文件负责一块逻辑，命名清晰，看起来很有条理。`index.html` 大概长这样：

```html <!DOCTYPE html> <html> <head> <title>用户管理</title> <link rel="stylesheet" href="css/style.css"> </head> <body> <h1>用户列表</h1> <div id="user-list"></div> <script src="js/lib/jquery.js"></script> <script src="js/lib/underscore.js"></script> <script src="js/utils/dom.js"></script> <script src="js/models/User.js"></script> <script src="js/views/UserView.js"></script> <script src="js/app.js"></script> </body> </html> ```

看起来一切正常，对吧？六个 script

接着你写 `js/app.js`，里面会用 `var` 声明一些全局变量、用 `jQuery` 的 `$`、调用 `UserView.render()`——一切都"看起来能跑"。在开发环境里，你刷新几次页面都没有问题，然后你把项目部署到线上，几小时后客服那边反馈：

> "用户列表点编辑按钮没反应，控制台报错 `UserView is not defined`。"

你打开自己的浏览器试了一下，本地一切正常，线上就是不行。你对比了一下两边的 HTML，发现本地和线上的 script 顺序完全一致——等等，`<script src="js/lib/jquery.js"></script>` 这一行的位置好像不太一样。原来你团队里另一个同事昨天优化"首屏加载"，把 jQuery 改成了异步加载：

```html <script async src="js/lib/jquery.js"></script> ```

他觉得这样可以让浏览器"并行下载"。问题在于，异步加载意味着执行顺序不确定。浏览器不再保证 jQuery 先于 `app.js` 执行。结果就是：`app.js` 里的 `$` 还没拿到，jQuery 才姗姗来迟。更糟糕的是，他只改了 jQuery 这一行，却让整个项目的执行顺序都变得不可预测。

这就是典型的"看似能跑"的陷阱。在浏览器直接用 `<script>` 标签加载代码，本质上是手动管理依赖——依赖顺序、依赖完整性、依赖隔离，全部依赖开发者自己小心谨慎。这种开发模式扩展性极差，当我们把视野放宽，会发现至少有五类问题在困扰着多文件 jQuery 项目：

问题一：脚本顺序的脆弱性。 顺序只能由人来保证，一旦有人改了一行顺序——比如把 underscore 放到 app.js 后面、或者把 jquery 改成 async、或者把某个文件 defer 掉——整个应用的执行顺序就可能被打破。JavaScript 文件之间没有"声明依赖关系"的机制，每引入一个新文件都意味着一次全局状态的赌博。

问题二：全局作用域的污染。 在浏览器里，所有 `<script>` 标签加载的代码共享同一个全局作用域，也就是 `window` 对象。你在 `dom.js` 里写了 `var helper = {};`，在 `User.js` 里写了 `var User = function () {};`，这些变量会全部挂载到 window 上。假设你引入了一个第三方库，它恰好也定义了一个叫 `User` 的变量——冲突发生了，而且这种冲突往往不会被编辑器或浏览器提醒你，要等到运行时才会爆出来。更隐蔽的是命名冲突：两个开发者各自定义了 `helper`、`utils`、`config`，最后谁也不知道哪个版本生效。

问题三：依赖关系的隐式与不透明。 想象一个新同事加入团队，他打开 `index.html`，看到六个 script 标签，他必须人肉推断每个文件的依赖——`app.js` 用到了 `$`、`User`、`UserView`，所以 `app.js` 必须放在最后。他需要阅读每一个文件的内容才能画出依赖图。这种隐式依赖随着文件数量线性增长，到几十个文件时几乎无法管理。

问题四：无法使用现代语言特性。 ES6（2015 年发布）引入了 `import` / `export` 语法、箭头函数、`class`、`const` / `let`、Promise、模块化等等。但浏览器原生支持这些特性是渐进式的——IE 11 完全不支持 ES6，即便到今天，2020 年以前的浏览器对很多新特性也支持不全。如果直接写 `import`，老用户打开页面只会看到一片空白。

问题五：性能与上线流程的原始。 你开发环境用的是未压缩的、源码格式的 JavaScript，包含注释、换行、未缩短的变量名——这适合人阅读，但不适合线上传输。一份 jQuery 1.x 源码大约 270KB，gzip 后还有 70 多 KB。上线前你需要手动压缩、手动合并、手动重命名、手动处理缓存——这一切都靠开发者"记得做"，而不是被工具强制执行。

这些问题并不是哪个开发者不细心，而是工具本身不支持工程化的结果。当一个项目超过十个 JavaScript 文件、超过三个开发者、上线频率高于每周一次，这种"原始模式"就会从能用变成糟糕，最终变成不可维护。

1.2 什么是"前端工程化"

面对上面的问题，行业慢慢形成了一个共识：前端不应该是"写几个脚本嵌入 HTML"的小作坊，它应该像后端、移动端一样，是一种工程化的开发方式。所谓工程化，指的是用工具、流程、规范来保障项目的可维护性、可协作性、可交付性。具体到前端，工程化要解决的核心问题可以归纳为五点：

第一，模块化。 把代码拆成一个个职责单一的文件，并且让文件之间能够显式地声明依赖。A 文件用到 B 文件，应该通过某种语法明确写出来，而不是靠注释或者靠全局变量"默契约定"。这样无论是新人接手、还是工具分析代码、还是上线前的合并压缩，都有据可依。模块化是工程化的基石——没有模块化，后面所有的优化都只能在小修小补里打转。

第二，自动化。 凡是重复的、人会忘记的步骤，都应该交给工具执行。代码压缩、CSS 预处理、文件合并、图片压缩、ES6 转 ES5、按需加载、自动刷新、自动部署——这些工作如果靠开发者手动做，做多了一定会出错。工程化的目标是让开发者只关心业务逻辑，把脏活累活全部交给构建流水线。

第三，可维护性。 项目应该易于阅读、易于修改、易于扩展。这要求有统一的代码风格（通过 ESLint 强制）、统一的目录结构、统一的依赖管理方式。当项目从一千行代码增长到十万行时，可维护性的差异决定了项目能不能活过一年。

第四，性能优化。 页面加载速度直接影响用户体验和业务指标。工程化要解决的问题包括：减少 HTTP 请求数（合并文件）、减小文件体积（压缩、Tree Shaking）、按需加载（Code Splitting）、浏览器缓存策略、CDN 加速、首屏渲染优化等。这些优化需要构建工具的深度参与。

第五，协作流程。 现代前端不是一个人写代码，而是多人协作。代码如何合并（Git 分支策略）、依赖如何管理（package.json）、如何避免覆盖彼此（模块隔离）、如何保证上线质量（自动化测试 + 灰度发布）——这些都需要工程化的流程支撑。

把这五点放在一起看，你会发现它们是有内在逻辑的：模块化是底层基础，决定了代码能不能被工具识别和分析；自动化是手段，把人工劳动转化为机器流程；可维护性、性能、协作则是工程化要达到的目标。换句话说，工程化不是某个具体工具，而是一整套思维方式和工具链的组合。

1.3 构建工具的演进简史

理解工程化的最好方式，是看构建工具如何一步步走到今天。我把这段历史分成四个时代，每个时代都对应一种核心痛点。

时代一：手工脚本时代（2008 年以前）。 在 jQuery 流行的早期，几乎没有"构建"概念。开发者要上线一个项目，最常做的事情就是打开 YUI Compressor 或者 Google Closure Compiler，把几个 JavaScript 文件手动压缩一下，输出一个 `app.min.js`，手动替换 HTML 里的引用。那时候的工具本质上是"单文件压缩器"，它们不知道文件之间有什么关系，更不参与模块管理。这个时代的特点是：工具只做一件事，其他都靠人。

时代二：任务流时代（2012—2015，Grunt / Gulp）。 随着项目变复杂，开发者意识到上线要做的事远不止"压缩 JS"——还要压缩 CSS、合并雪碧图、编译 Sass、监听文件变化、刷新浏览器、跑测试。Grunt（2012）和 Gulp（2013）应运而生。它们的核心思想是把一系列任务串成一个流水线：先 lint，再编译，再合并，再压缩，再拷贝到输出目录。Grunt 基于 JSON 配置，Gulp 基于"代码即配置"的流式写法。这个时代的工具第一次让"自动化"成为可能，但它们依然不关心模块化——它们只负责"按顺序执行你让我做的事"，至于文件之间的依赖关系，依然要开发者手动配置。

时代三：万物皆模块时代（2015—2020，Webpack / Rollup / Parcel）。 这一阶段是构建工具的范式跃迁。Webpack（2012 年发布，2014 年开始流行）提出了一个革命性的口号："一切皆模块"。JavaScript 是模块、CSS 是模块、图片是模块、字体也是模块。每个模块可以引用其他模块，构建工具会自动从入口文件开始，沿着 import 语句递归解析整张依赖图，最终把所有模块打包成浏览器能直接运行的静态资源。这彻底解决了 jQuery 时代"手动管理脚本顺序"的痛点：你只需要在每个文件里写 `import './other.js'`，构建工具会自动决定加载顺序、自动合并、自动优化。

Webpack 的另一大贡献是Loader 和 Plugin 机制。Loader 让工具可以处理任意类型的文件（CSS 用 css-loader、图片用 file-loader、ES6 用 babel-loader），Plugin 让工具可以介入构建的每一个阶段（生成 HTML、抽取 CSS、压缩代码、注入环境变量）。这种可扩展性使得 Webpack 几乎能胜任任何前端场景，因此迅速成为事实标准。Rollup 则更专注于 JavaScript 库的打包（更小的产物体积、更好的 Tree Shaking），Parcel（2017）以"零配置"为卖点，进一步降低了使用门槛。

时代四：原生 ESM 时代（2020 至今，Vite / esbuild / Snowpack）。 Webpack 解决了模块化问题，但它也有代价：项目越大，构建越慢。因为它本质上要在启动时先把所有模块打包成 bundle，开发服务器才能跑起来。一个几千个模块的中型项目，Webpack 冷启动可能要 30 秒到 1 分钟，热更新也要几秒。Vite（2020 年发布）的思路是反其道而行之——既然现代浏览器已经原生支持 ES Module（`<script type="module">`），那开发阶段为什么不直接让浏览器按需加载源文件呢？Vite 在开发环境利用浏览器原生 ESM，不做打包，启动时间可以做到几百毫秒，热更新几乎是即时的。它只在生产环境用 Rollup 做一次完整构建。这种"开发用原生、生产用打包"的混合策略，既享受了 ESM 的轻量，又保留了生产环境的优化能力，成为 2020 年后新建项目的首选。

把这四个时代连起来看，构建工具演进的主线，是"把开发者从手工劳动里解放出来"的程度不断加深：从手动压缩（解放 10% 的工作），到任务流（解放 50%），到依赖图打包（解放 80%），再到原生 ESM + 按需编译（解放 90%）。这是一条清晰可辨的工程化进程。

1.4 一个对比：未工程化 vs 已工程化

光说概念太抽象，我们用同一个需求对比两种实现方式，看清楚"工程化"到底加了什么。

需求：做一个"待办事项"页面，可以添加任务、勾选完成、删除任务，状态保存到 localStorage。

未工程化的实现：一个 `index.html`，三个 `<script>`，代码全部塞进全局作用域。

```html <!DOCTYPE html> <html> <head> <title>待办事项</title> <link rel="stylesheet" href="style.css"> </head> <body> <h1>待办事项</h1> <input id="todo-input" placeholder="输入待办..."> <button id="add-btn">添加</button> <ul id="todo-list"></ul>

<script src="storage.js"></script> <script src="todo.js"></script> <script src="app.js"></script> </body> </html> ```

```javascript // storage.js var storage = { get: function (key) { return JSON.parse(localStorage.getItem(key) || '[]'); }, set: function (key, value) { localStorage.setItem(key, JSON.stringify(value)); } };

// todo.js var Todo = function (text) { this.text = text; this.done = false; };

// app.js var list = document.getElementById('todo-list'); var input = document.getElementById('todo-input'); var btn = document.getElementById('add-btn');

var todos = storage.get('todos') || [];

function render() { list.innerHTML = ''; todos.forEach(function (todo, i) { var li = document.createElement('li'); li.textContent = todo.text; if (todo.done) li.style.textDecoration = 'line-through'; li.onclick = function () { todo.done = !todo.done; storage.set('todos', todos); render(); }; list.appendChild(li); }); }

btn.onclick = function () { if (!input.value) return; todos.push(new Todo(input.value)); storage.set('todos', todos); input.value = ''; render(); };

render(); ```

这套代码能跑，但有三个隐患：第一，`storage`、`Todo`、`todos`、`render` 全是全局变量，如果页面里再加载别的脚本，命名冲突随时可能发生；第二，三个文件的顺序是手写的，写错了 `Todo` 就是 `undefined`；第三，没有压缩、没有缓存策略、没有现代语法、没有自动化测试——所有的上线工作全靠开发者"记得做"。

工程化的实现：拆成多个模块，用 ES Module 组织，用 npm 管理依赖，用 Vite 跑开发服务器和打包。

目录结构：

``` todo-app/ ├── src/ │ ├── main.js │ ├── storage.js │ └── todo.js ├── index.ht