⚡ Vite

一句话定性

Vite 的成功来自一次第一性原理的发问:“为什么开发时一定要先打包?” 当现代浏览器原生支持了 ES-Modules,这个前提就不再成立了。Vite 抛弃 dev 打包,实现 no-bundle dev,冷启动从几十秒变成几百毫秒——这是对 Webpack 在开发体验上的降维打击。


一、它是什么 & 出现的时代

Vite(法语”快”,2020,作者尤雨溪 Evan You,也是 Vue 作者)是新一代前端构建工具。它诞生于 2018-2023 工程化时代——彼时 Webpack 已统治十年,但”冷启动慢、HMR 慢”的怨气积累到了顶点。

Vite 不是又一个打包器,它是对”开发期构建”这件事的重新设计


二、为什么会出现(解决上一代什么痛点)

Webpack 的致命伤:dev 也要打包

  1. 冷启动慢:Webpack 开发模式必须把整个应用打成 bundle 才能启动 dev server。项目越大越慢,大项目几十秒到几分钟,严重打断心流。
  2. HMR 随规模变慢:改一行,要重新构建受影响的 chunk,大项目要等几秒。
  3. JS 工具性能触顶:Webpack + Babel 都是 JS 写的,优化到头也快不过编译型语言。

核心矛盾:Webpack 诞生时浏览器不支持模块,所以”dev 必须打包”天经地义。但到 2020 年,这个前提已经悄悄失效了——而工具还在按旧前提运行。


三、核心机制 & 为什么快

两套引擎:dev 用原生 ESM,prod 用 Rollup

① 开发:no-bundle + 浏览器原生 ES-Modules 现代浏览器原生支持 <script type="module">import。所以 Vite 开发时根本不打包:它直接把源码作为 ESM 喂给浏览器,浏览器请求哪个模块,Vite 才即时编译那一个模块(按需编译)。

传统(Webpack):
  启动 ──► 把【整个应用】打成 bundle ──► 几十秒后才能用 ◄── 项目越大越慢

Vite(no-bundle):
  启动 ──► 几乎瞬间(只启 dev server)
  浏览器请求 main.js ──► 它 import 了 a.js ──► 浏览器再请求 a.js
  Vite 只在【被请求时】即时编译那一个文件  ◄── 启动时间与项目大小几乎无关

② 依赖预构建(dependency pre-bundling)用 esbuild 两个问题需要预构建:① 很多 npm 包还是 CommonJS,浏览器 ESM 不认;② 像 lodash 这种由几百个小模块组成的包,如果每个都让浏览器单独请求,会有几百个请求(瀑布流)。Vite 用 esbuild(Go,比 Babel 快 10–100 倍) 把依赖预先转成 ESM 并合并,只在第一次启动时做一次,之后缓存。

③ HMR 基于原生 ESM,精确且恒定快 改一个模块,Vite 只让浏览器重新请求那一个模块,HMR 速度与项目大小无关,始终很快。

④ 生产:用 Rollup 打包 开发不打包,但生产环境仍需打包(为了 tree-shaking、code splitting、兼容性、减少请求数)。Vite 把这活交给成熟的 Rollup。dev 和 prod 用不同引擎,各取所长。

为什么快的完整论证见 为什么Vite能取代Webpack


四、带来的新问题 / 副作用

dev/prod 不同引擎的代价

  1. dev 与 prod 行为可能不一致:dev 用原生 ESM + esbuild,prod 用 Rollup,两条路径偶尔会有”dev 正常、build 出问题”的诡异 bug。
  2. 首次冷启动有预构建开销:第一次启动或依赖变化时,esbuild 预构建要花点时间(之后缓存)。
  3. 超大量模块时,首屏请求数多:no-bundle 下,极端复杂的页面首次加载可能产生大量模块请求(已被 HTTP/2 和按需缓解,但仍存在)。
  4. 两套工具的复杂度:当你需要深度定制,要同时理解 esbuild 和 Rollup 的插件体系。
  5. 生态迁移成本:从 Webpack 的 loader/plugin 生态迁过来,部分能力要找替代。

五、为什么会衰落 / 现状

Vite 远未衰落,正处于上升期

现状(2026):

  • 新项目默认选择:Vue、React、Svelte 等脚手架普遍默认 Vite,SvelteKit/Nuxt 等元框架以它为底座。
  • 正在解决自身的内部矛盾:dev(esbuild)和 prod(Rollup)两套引擎不统一,是 Vite 已知的架构债。团队正用 Rolldown(Rust 重写的 Rollup)来统一 dev/prod,延续 Rust 工具链潮流。
  • 主要竞争来自 Turbopack(Vercel/Next.js 阵营)和 Rspack(字节)——都是 Rust 打包器,在”增量计算 + 大型应用 build 速度”上与 Vite 竞争。

六、对后续技术的影响(因果链)

[[Webpack]] dev 必须打包 ──► 冷启动慢(项目越大越慢),怨气积累
        │
        ▼  前提变了:现代浏览器原生支持 [[ES-Modules]]
        │
Vite:第一性原理 ──"开发时根本不需要打包"
        │  ① no-bundle dev + 原生 ESM ──► 冷启动几百毫秒,HMR 恒定快
        │  ② esbuild(Go)预构建依赖 ──► 处理 CJS + 合并小模块
        │  ③ prod 用 [[Rollup]] ──► tree-shaking / code splitting
        │
        ├──► DX 革命 ──► 证明"开发体验本身就是核心竞争力"
        │
        ├──► 成为元框架(SvelteKit/Nuxt/Astro)的标准底座
        │
        └──► dev/prod 双引擎是债 ──► Rolldown(Rust)统一,延续 Rust 工具链潮
        │
        ▼
激起 Rust 打包器竞赛:[[Turbopack]]、Rspack 同台竞争

历史地位

Vite 是”重新审视前提”的典范。Webpack 没做错任何事——它只是建立在一个后来失效的前提(浏览器不支持模块)上。Vite 的贡献不是发明了更快的打包算法,而是发现了”这个场景下根本不需要打包”。这是第一性原理最漂亮的应用:不优化旧答案,而是质疑旧问题。


🔗 相关:前端工程化演进史 | Webpack | Rollup | ES-Modules | Babel | Turbopack | 为什么Vite能取代Webpack | Vue | 2018-2023 工程化时代