Q02：Vite 8 已经用 Rolldown 统一替代了 esbuild + Rollup 双引擎，这解决了什么问题？之前双引擎时代有哪些痛点？
⏱ 预计阅读时间：4 分钟
原题：Vite 8 已经用 Rolldown 统一替代了 esbuild + Rollup 双引擎，这解决了什么问题？之前双引擎时代有哪些痛点？
🎯 面试官在考什么
- 考点1：双引擎架构的根本矛盾——开发用 esbuild、生产用 Rollup 的行为不一致
- 考点2：Rolldown 统一引擎的设计动机与技术优势（Rust + Rollup 兼容）
- 考点3：Vite 8 的实际迁移体验和配置变化
✅ 答题框架（建议顺序）
- 先说双引擎痛点：esbuild（Go）负责开发环境（预构建、TS/JSX 转换），Rollup（JS）负责生产打包——两套转换管线导致开发/生产行为不一致、插件系统不统一、边缘 case 频出
- 再说具体痛点展开：①同样的代码开发和生产构建结果不同（如 CSS 处理差异、模块副作用判定差异）② esbuild 和 Rollup 插件 API 不兼容，中间需大量胶水代码 ③ 缓存不共享，开发缓存和生产缓存各自维护
- 最后说 Rolldown 如何解决：Rust 编写、性能对标 esbuild、兼容 Rollup 插件 API——一套引擎跑通开发和生产，行为完全一致，插件生态无缝继承。Vite 8 还内置兼容层，
esbuild和rollupOptions配置自动映射到 Rolldown/Oxc 等效配置
⚠️ 常见踩坑
- 把"双引擎痛点"只说成"速度慢" → 核心痛点不是速度，而是行为一致性。esbuild 和 Rollup 对同一模块的转换逻辑不同，才是最让开发者头疼的
- 认为 Rolldown 是 Rollup 的 Rust 重写 → 不准确。Rolldown 是独立实现的打包器，但兼容 Rollup 插件 API，这是生态迁移的关键设计
- 认为 Vite 8 升级需要大量改配置 → 实际上 Vite 8 内置兼容层，多数项目零配置即可迁移。
optimizeDeps.esbuildOptions改为optimizeDeps.rolldownOptions是少数需手动调整的项
💎 加分项
- 提到 Vite 8 + Rolldown + Oxc 三件套：Vite（构建工具入口）→ Rolldown（打包器）→ Oxc（编译器/解析器），形成端到端 Rust 工具链，语义分析能力增强带来更优 Tree-shaking
- 带实际性能数据：Linear 构建从 46s → 6s、Ramp 减少 57%、Mercedes-Benz.io 减少 38%
- 提到 Full Bundle Mode（实验性）：Vite 8 引入的开发模式新选项，开发阶段也执行完整打包，解决大工程瀑布请求问题
📚 关键知识点速查
- esbuild：Go 编写的超高速 JS/TS 编译器，Vite 早期用于开发环境的依赖预构建和 TS/JSX 转换
- Rollup：JS 编写的打包器，以 ESM 优先和优秀的 Tree-shaking 著称，Vite 早期用于生产构建
- Rolldown：Rust 编写的打包器，性能对标 esbuild、兼容 Rollup 插件 API，Vite 8 起统一替代双引擎
- Oxc：Rust 编写的 JS/TS 编译器集合，Vite 8 中负责解析/转换/压缩，替代 esbuild 的编译角色
- 兼容层：Vite 8 内置的配置映射机制，自动将
esbuild和rollupOptions转为 Rolldown/Oxc 等效配置 - Full Bundle Mode：Vite 8 实验性开发模式，在开发阶段也执行完整打包，减少瀑布请求
优先级：🔴高频
