Vite 8 Beta：把打包器从 Rollup/esbuild 换成 Rust 写的 Rolldown
阅读时间: 大约 10 分钟
Vite 8 Beta：把打包器从 Rollup/esbuild 换成 Rust 写的 Rolldown
2025 年 12 月 3 日，Vite 团队发布了 Vite 8.0.0-beta.0。这次版本的变化不在表面 API，而在底层：Vite 此前为开发环境和生产环境分别使用 esbuild 与 Rollup 两套打包管线，8.0 起统一改用 VoidZero 团队用 Rust 编写的 Rolldown 作为唯一打包器，并搭配同为 Rust 项目的 Oxc 做解析、转译与压缩。官方称这一换绑器带来”显著更快的生产构建”。本文按官方博客原文，把可核对的数字与需要警惕的口径分开讲。
一、为什么要换：双管线的一致性成本
Vite 的经典架构是”快是因为双轨”：开发阶段用 esbuild 做即时编译（依赖预构建 + 模块转译），生产阶段用 Rollup 做真正的打包、分包与产物优化。这种分工让 Vite 不必重造解析器，但也带来了长期技术债——官方在博客里明确列出三点：
- 开发与生产是两套独立的转译管线；
- 二者插件系统不同；
- 为了让 dev 与 build 行为对齐，积累了越来越多的”胶水代码”。
结果就是同一个项目在 vite dev 下正常、在 vite build 下却出现产物差异。Rolldown 的目标正是用一个 Rust 实现同时满足开发与生产，从根上消除这种不一致。
二、Rolldown 是什么：一个团队、一条工具链
Rolldown 由 Vite 的主要维护者所在的 VoidZero 团队开发，定位是”面向 Web 的下一代打包器”。它用 Rust 编写，设计目标有三：性能、兼容性、特性扩展。值得注意的是它不只是一个 bundler——Rolldown 使用同属 VoidZero 的 Oxc 来完成解析器（parser）、解析器（resolver）、转译器（transformer）与压缩器（minifier）。
官方因此把这次换绑器描述为一次”工具链统一”：构建工具（Vite）、打包器（Rolldown）、编译器（Oxc）现在由同一个团队维护。这样做的好处是可以直接复用 Oxc 的语义分析能力做更准确的 tree-shaking，而不必在 JS 侧反复对齐。
三、可核对的性能数据
官方博客给出的性能数字分两类：一类是 Rolldown 自身相对 Rollup 的倍率，另一类是早期 rolldown-vite 技术预览阶段真实接入方的构建时间变化。整理如下：
| 指标 | 官方数值 | 口径与来源 |
|---|---|---|
| Rolldown vs Rollup | 快 10–30× | 官方博客原文，Rolldown 团队自测 |
| Rolldown vs esbuild | “性能与 esbuild 相当” | 官方博客定性描述，未给具体倍率 |
| Linear 生产构建 | 46s → 6s | rolldown-vite 早期接入方自述 |
| Ramp 构建时间 | 下降 57% | 早期接入方自述 |
| Mercedes-Benz.io 构建时间 | 最多下降 38% | 早期接入方自述 |
| Beehiiv 构建时间 | 下降 64% | 早期接入方自述 |
| Full Bundle Mode（未发布） | dev 启动 3×、全量 reload 40% 更快、网络请求 10× 更少 | 官方称”preliminary results”，尚未进入 beta |
四、迁移路径与新增特性
官方强调 Vite 8 尽量保持配置 API 与插件 hooks 不变，并提供两条升级路径：
- 直接升级：把
package.json里的vite改为8.0.0-beta.0，照常跑 dev/build； - 渐进迁移：先从 Vite 7 切到
rolldown-vite包，确认无兼容问题后再切到 Vite 8——官方建议大型或复杂项目走这条路。
如果项目本身是框架（如 Astro、Nuxt、Vitest）而非直接依赖 Vite，则需要在 package.json 里通过 overrides/resolutions/pnpm.overrides 强制覆盖传递进来的 vite 版本。
Vite 8 还附带两个开箱即用的 TypeScript 相关特性：内置 tsconfig.json 的 paths 映射支持（通过 resolve.tsconfigPaths: true 开启，官方提示有少量性能开销，默认关闭），以及对 TS emitDecoratorMetadata 的内置自动支持。
五、评测口径与局限：哪些数字现在还不能当真
这一节是本文重点。官方博客里的数字需要区分”已核实”与”官方称”：
- 10–30× 是 Rolldown 团队自己的基准测试，对比对象是 Rollup，而非某个真实业务项目；它衡量的是打包器本身，不代表你的项目一定提速这么多。
- Linear/Ramp/Mercedes-Benz.io/Beehiiv 的数字是早期接入方在
rolldown-vite上的自报结果，样本量小、硬件与项目规模各异，且属于营销性质的”perf wins”，不能当作普遍预期。 - Full Bundle Mode 的 3×/40%/10× 是”preliminary results”，官方明确说该模式”soon”才发布，并不包含在当前 beta 里，不能拿来评估 Vite 8 beta。
- beta 本身就是不稳定状态：官方专门提示，如果你依赖某些 Rollup 或 esbuild 的特定配置项，迁移到 Rolldown 后可能需要调整配置，并建议升级后充分测试、遇到问题回报 issue。
- 官方还为 SvelteKit、react-router、Storybook 等框架/元框架专门建了插件兼容性 CI，但兼容性覆盖面仍在爬坡。
六、适用与不适用人群
- 适合现在就试：构建已经明显偏慢、且愿意把它当技术预览跟进的中大型项目；先在
rolldown-vite上跑通再上 Vite 8 beta。 - 适合关注但不必急着升级：绝大多数线上生产项目。beta 阶段配置项兼容性尚未完全收敛，等 8.0 正式版与各框架完成适配更稳妥。
- 值得跟进的长期方向：官方提到的 Raw AST transfer（让 JS 插件以极低开销访问 Rust 产出的 AST）与 Native MagicString transforms（简单变换逻辑写在 JS、计算在 Rust），指向”插件生态仍用 JS、但底层吃 Rust 性能”的路线，这对 Vite 插件作者尤其重要。
七、它意味着什么
Vite 8 的本质不是一次常规大版本，而是把整个前端构建底座从 JS 生态（Rollup + esbuild）迁移到 Rust 生态（Rolldown + Oxc）。短期看是构建提速，中期看是 dev/prod 行为终于对齐，长期看则是 Vite 插件体系如何与 Rust 内核共存的问题。对使用者而言，现在最理性的姿势是：把它当作一次有官方背书、但仍需自测的底层迁移来跟踪，而不是立刻替换生产构建。