构建

前端构建真正要解决的，不是“会不会背 Vite、Webpack、Rollup 的名字”，而是：开发时写的源码、依赖和静态资源，为什么最后能变成浏览器高效加载和运行的产物。

1. 构建在前端知识体系里的位置

如果 HTML、CSS、JavaScript、TypeScript 负责表达页面和逻辑，那构建负责的就是：

1. 组织源码依赖关系
2. 做语法编译和兼容性处理
3. 打包和输出浏览器可运行产物
4. 优化加载性能与缓存效率

也就是说，构建不是独立于业务之外的边角知识，而是现代前端应用交付链路的一部分。

1.1 为什么构建会成为前端工程的复杂度中心

很多人一开始会觉得，构建只是“把代码编译一下、打包一下”。但项目一旦进入工程化阶段，构建很快就会变成复杂度最集中的位置，因为它正好处在这些矛盾的交汇点上：

1. 开发态希望源码可读、改动反馈快
2. 浏览器运行态希望资源少、加载快、兼容性稳定
3. 团队工程态还希望目录清晰、依赖可控、问题可排查

这三件事天然不是一回事。

例如：

1. 开发时你希望保留模块边界，方便定位和热更新
2. 线上时你又希望把公共依赖抽离、静态资源压缩、文件名带哈希
3. 某些语法开发时写起来很自然，但浏览器并不能直接理解

所以构建的本质，不只是“转换代码”，而是：在开发体验、浏览器约束和线上交付之间做一整套组织、转换和优化。

1.2 可以用一条总链路理解构建

如果先不区分 Webpack 和 Vite，只从整体上理解，前端构建通常都在做下面这条主线：

flowchart TD
    A[编写源码 HTML CSS JS TS 与静态资源] --> B[分析模块依赖关系]
    B --> C[对不同类型文件做转换]
    C --> D[形成可运行的模块结果]
    D --> E[根据策略拆分或合并产物]
    E --> F[生成浏览器最终请求的文件]
    F --> G[浏览器加载 执行 缓存]

这条主线最关键的价值在于，它把几个经常被混在一起的动作拆开了：

1. 分析：谁依赖谁，哪些模块会进入当前页面
2. 转换：TypeScript、JSX、CSS、图片等如何变成构建链可理解的结果
3. 组织：模块如何拆包、合包、共享和缓存
4. 输出：最终浏览器到底请求哪些文件

真正理解这条链之后，再去看 Webpack 和 Vite，就不会只剩“谁更快、谁配置更重”这种表层印象。

2. 这部分会重点覆盖哪些主线

当前这个目录先只保留两条真正需要深入展开的工具主线：

1. Webpack 详解
2. Vite 详解

3. 为什么要拆成多篇笔记

如果把构建所有内容揉进一篇里，通常会出现：

1. 基础概念和具体工具混在一起
2. 编译、打包、缓存优化彼此打断
3. “为什么这样设计” 和 “怎么落地” 难以同时讲清

但如果拆出太多“基础概念页”，又会出现另一种问题：

1. 目录被介绍型内容切碎
2. 真正需要深挖的工具主线反而不突出
3. 读者会感觉一直在看前置说明，而不是进入具体知识点

所以当前更稳的做法是：

1. 一篇总览页建立全局认知
2. 只保留 Webpack 和 Vite 两篇核心专题
3. 其他构建基础概念优先收敛到这两条主线内部讲清

4. 推荐阅读顺序

如果是第一次系统整理前端构建，阅读顺序：阅读：

1. 看 Webpack 详解
2. 再看 Vite 详解

这样阅读的好处是：

1. 先进入真正的工具主线
2. 相关构建概念会在工具语境里自然出现
3. 不会先被过多介绍型页面打断

5. 一句话先建立整体认知

可以直接记住：前端构建的本质，是把面向开发的源码和资源，转换成面向浏览器高效运行和加载的最终产物。