vite为什么冷启动快？

蔓越莓
2 阅读4分钟

vite演变时间线

版本发布时间Dev 依赖预构建生产打包工具核心特点（考点）
Vite 1.x2020‑04RollupRollup单引擎；仅优先支持 Vue3；浏览器原生 ESM；预构建 Rollup (JS)，速度慢；生态有限，只面向 Vue 项目
Vite 2 ~ 62021‑02 ~ 2025‑09esbuildRollup🔥双引擎架构；全框架通用，插件生态成熟；dev 速度大幅提升；dev/prod 两套工具，存在行为不一致风险
Vite 72025‑11esbuildRollup稳定版依旧双引擎；Rolldown+Oxc 仅为实验包rolldown‑vite，非默认启用；Node 版本抬高，为 Vite8 铺路
Vite 8+（最新稳定）2026‑03Rolldown+OxcRolldown+Oxc✅统一 Rust 管线；dev/build 同一套逻辑，彻底消除环境不一致；Oxc 做解析 / 转译 / 压缩，Rolldown 做打包分块

vite2为了提高冷启动速度，把dev的依赖预构建从Rollup换成了ESbuild；生产还保留Rollup；但因为双引擎带来的不一致问题，在vite8中又替换成了Rust写的Rolldown+Oxc来统一成一套；

vite 冷启动原理，为什么冷启动快？

  • 传统 Webpack：先把全部源码打包编译成 bundle，打包完再启动服务，项目越大打包越慢。

  • Vite 开发模式核心：基于浏览器原生 ESM，抛弃全量打包

    • 预构建（esbuild） 用 esbuild 把第三方依赖（node_modules）提前预打包成 ESM 模块。

    第三方依赖不变，做缓存；esbuild 是 Go 写的，编译速度远快 JS 工具。

    • 源码不整体打包业务源码不提前打包，启动 devServer，浏览器请求哪个文件，Vite 才实时编译、转换该单个文件返回给浏览器。按需加载

      • 浏览器发 import 请求 → Vite 拦截请求 → 转译单文件（ts/vue/jsx）→ 返回处理后的 ESM 给浏览器。
      • 项目再大，启动时只做依赖预构建，不需要处理业务源码，所以冷启动几乎不受业务代码体量影响。

总结：

  • Webpack：启动 = 全项目编译打包 → 再开服务
  • Vite：启动 = esbuild 预构建依赖 + 开启 devServer，业务代码请求时才编译

短板：大量模块同时导入时，浏览器会发起大量 http 请求，所以才需要预构建把细碎依赖合并成少量文件，减少网络请求。

知识点补充：依赖预构建

1.1.1 定义

只有开发环境 对 【 第三方依赖包】 提前 转译+打包

1.1.2 为什么需要？

vite dev核心思路是浏览器直接请求原生的ESM，源码不打包，按需加载，

但是有的第三方包是用CommonJS写的，浏览器不认识，所以需要先转成浏览器认识的ESM；

同时为了防止浏览器串行发起几百个http请求，页面太卡；所以需要将第三方包里成千个小文件合并成一个bundle；输出到node_modules/.vite/deps（预构建缓存目录，依赖不变，直接复用

1.1.3 预构建主要解决什么？（❤️重要）

  • 转译：转CJS
  • 打包：合并上千小文件成一个bundle

1.1.4. 预构建产物目录

预构建产物实际放在子文件夹：node_modules/.vite/deps, 浏览器还会对预构建的模块做 HTTP 强缓存（max‑age=31536000,immutable）

package.json依赖、lock 文件、vite.config的optimizeDeps、NODE_ENV发生变化，会触发重新预构建。

node_modules/.vite/
├─ deps/                # esbuild预构建输出，CJS转ESM后的库文件
└─ _metadata.json       # 缓存元数据：lock文件hash、依赖列表，用来判断要不要重新预构建

1.1.5 为什么只针对第三方包，业务源码不用预构建？

  • 浏览器路由分割按需请求ESM，所以天然不存在同时请求多的问题
  • 单个文件如果写了CJS，vite开发服务器收到请求的时候，单文件会实时用ESBuid转译返回

也就是说业务和第三方的代码都需要进行转译，只是时机，机制不一样；

1.1.5.1 预构建的范围是vite自动识别的
1.1.5.2 如果业务代码一起打包呢？

⚠️ vite dev模式的核心优势就是源码不打包 原生ESM按需加载，HMR极快；

如果src源码也打包的话：

  • 那么启动速度就会变回传统打包工具 要全量构建，丢掉vite最大卖点；
  • 同时HMR变慢；

业务源码频繁改动，不适合提前打包，而第三方的包很少改动，可以提前打包 缓存起来；

Vite 生产环境为什么不用 esbuild，改用 Rollup？

esbuild 打包速度快，但产物的代码分割、tree‑shaking、各种产物优化能力不如 Rollup 成熟。生产环境优先追求产物质量，不是构建速度，所以生产用 Rollup。

avatar
文章
阅读
粉丝