Vite 为什么需要 Vite
在正式动手之前，先回答一个最关键的问题，Vite 到底解决了什么。很多初学者一上来就照着文档敲命令，却不清楚自己为什么要用它，结果遇到报错就无从下手。这一篇我们从前端开发的演变讲起，帮你建立对构建工具的直观认识。
从三剑客到现代前端
最早写网页，只需要三个文件。
<!-- index.html -->
<h1>你好</h1>
<link rel="stylesheet" href="style.css">
<script src="app.js"></script>这种「HTML + CSS + JavaScript」三剑客的写法，浏览器直接打开就能运行，不需要任何额外工具。它的优点是简单，缺点是难以扩展。当项目变大，你会遇到这些问题。
- 一个页面要引入几十个 JS 文件，手动管理依赖顺序很痛苦。
- 没有模块系统，变量容易互相污染。
- 想用 Less、TypeScript 这些更先进的语法，浏览器不认识。
- 代码没有压缩合并，上线后加载很慢。
于是社区引入了 ES Module（浏览器原生模块）和各种预处理语言，但这些「高级写法」浏览器并不能直接运行，必须先经过一道转换和打包，这就引出了构建工具。
传统构建工具的工作方式
以 Webpack 为代表的传统工具，核心思路是「先打包，再运行」。
- 启动时，它从入口文件开始，把项目中所有被引用的模块全部分析一遍。
- 把所有模块打包合并成一个或几个大文件（bundle）。
- 启动一个本地开发服务器来托管这些打包产物。
- 你在浏览器里看到的页面，实际上是「打包之后的结果」。
这种方式的第一个代价是启动慢。项目越大，需要分析的模块越多，打包耗时越长。一个中等规模的项目，等个十几秒甚至几十秒才能看到页面是常事。
第二个代价是热更新延迟。当你改了一行代码，传统工具往往要重新构建相关的整条依赖链，再把新 bundle 推给浏览器，页面可能要等很久才刷新。
第三个代价是配置复杂。为了告诉工具怎么处理各种文件，你需要写一长串 loader 和 plugin 配置，学习成本不低。
Vite 的诞生与设计哲学
Vite（法语里是「快」的意思）由 Vue 的作者尤雨溪团队开发，它的核心想法是，既然现代浏览器已经原生支持 ES Module，为什么还要在开发阶段把所有东西提前打包好？
Vite 的设计哲学是「把打包这件事，按需推迟」。
- 在开发阶段，它几乎不做打包，而是直接把源码以原生 ES Module 的形式交给浏览器，由浏览器自己去按需加载模块。
- 浏览器请求哪个模块，Vite 就实时编译哪一个，做到毫秒级启动。
- 在生产阶段，它才使用成熟的打包器做优化，保证上线体积和运行性能。
换句话说，Vite 把「开发时该快的地方」和「生产时该优化的地方」分开了，这也是它体验远超传统工具的根本原因。
Vite 是什么
Vite 不是一个单一工具，它由两个相互配合的部分组成。
第一部分是开发服务器。它基于原生 ESM，启动极快，并且内置了模块热替换（HMR），改代码后页面局部更新，不用整页刷新。
第二部分是构建指令。它使用 Rollup（下一代是 Rust 实现的 Rolldown）把你的代码打包成能够上线的静态资源，这个过程专注于体积优化和兼容性处理。
你可以把 Vite 理解成一个「开发体验 + 生产打包」的组合方案，它既管你写代码时爽不爽，也管你上线时跑得快不快。
本篇小结
- 传统构建工具「先打包再运行」，项目越大越慢。
- Vite 利用浏览器原生 ESM，开发时按需编译，启动几乎瞬时。
- Vite 由「开发服务器」和「构建指令」两部分组成。
下一篇我们来拆解 Vite 的核心原理，看看它到底「快」在哪里，以及开发环境和生产环境分别用了什么策略。