Vite 8 发布后圈子里最热闹的话题就是 Rolldown 正式上位替掉了以前那套 esbuild Rollup 双引擎组合。我第一时间把手头一个中型项目从 Vite 7 升到了 Vite 8跑完构建直接愣住生产构建时间从原来的 127 秒掉到 39.8 秒快 3.19 倍冷启动也从 3.8 秒压到了 1.1 秒。这个提升不是挤牙膏式的优化是换了个心脏级别的变化。这篇文章把我这次升级换芯的完整过程、配置迁移细节、实测数据对比以及踩过的坑和排查思路全部整理出来。不管你是正在观望要不要升级还是已经在升级路上碰到问题这份记录应该都能给你一个比较清晰的参照。如果你对前端构建性能比较敏感、经常被大型项目的构建时间折磨那这文特别适合你。1. 双引擎时代Vite 为什么需要两个构建工具要理解这次换芯的意义得先回头看清 Vite 以前那套双引擎架构是怎么来的以及它有哪些绕不过去的痛。1.1 开发与生产的分工esbuild 和 Rollup 各自承担什么Vite 启动项目时开发者体验好到离谱页面秒开改动热更新这套体验的主力是esbuild。esbuild 用 Go 写的速度极快Vite 让它负责两件事一是依赖预构建把 node_modules 里那堆 CommonJS、UMD 格式的包转换成浏览器能直接跑的 ESM顺便做依赖扁平化;二是开发服务器启动时对源码的 transform把 Vue/TSX 文件快速转译成 JS。但 esbuild 的角色只到开发环境为止。到了生产构建Vite 会切换成Rollup。Rollup 是插件生态最成熟的打包器以 tree-shaking 精准、产物可定制性强著称。它负责做真正的打包优化代码分割、按需加载、资源指纹、生成最终发布文件。这套架构在 Vite 5 之前的几个大版本里一直运行得挺稳定开发快、产物质量高各取所长。代价就是开发和生产其实是两套不同的转译和打包逻辑。1.2 “双引擎”带来的真实成本双引擎不是免费的。我在实际项目里感受最明显的问题有这么几个行为不一致esbuild 和 Rollup 对同一段代码的解析和转换结果有细微差异。开发环境跑得好好的一打生产包就出问题这类问题排查起来很费神。最常见的就是某些依赖在开发环境被 esbuild 预构建后导出形态正常但生产环境 Rollup 重新处理一遍后具名导入变成 undefined。依赖重复构建开发时 esbuild 已经预构建过一遍依赖生产时 Rollup 又要重新解析、转换、打包一遍同样的东西。同样的事情做两遍构建时间自然翻倍。内存压力大两个引擎在切换时都会各自维护一套模块图和转换结果项目一大型内存占用就明显上涨。我在 CI 上就遇到过构建中途 OOM后来不得不把 Node 内存上限从默认 4GB 调到 8GB。所以这次 Vite 8 用 Rolldown 把两个引擎换成一套链路不是单纯追求快还顺便把一致性和内存问题一起收拾了。2. Rolldown 换芯从“二换一”到真正的统一Rolldown 不是突然冒出来的新工具它是 VoidZero 团队Vite 核心团队同一批人用 Rust 写的打包器目标非常明确在 API 和插件生态上兼容 Rollup同时把性能做到接近 esbuild 的量级最终把开发和生产两条链路的执行引擎统一成一个。2.1 Rust 重写到底强在哪用 Rust 重写构建工具这件事这几年在前端圈已经不是新鲜事。SWC、Biome、Oxc走的都是这条路子。Rust 相对 Node.js 的优势主要在三个层面编译型语言的运行时开销低Node.js 是 JIT 解释执行Rust 是直接编译成机器码在循环遍历语法树、做字符串处理这种 CPU 密集场景下性能差距是数量级的。并行能力更强Rust 对多线程的支持比 Node.js 的 worker_threads 方案轻量得多。Rolldown 内部可以安全地多线程并行解析模块、并行执行 transform而 Rollup 受限于 JS 单线程模型大部分时候只能串行处理。内存控制更精确Rust 没有 GC 停顿内存布局由开发者控制稳定性和峰值内存都更好。但这里我必须强调一点Rust 不是银弹。很多同学以为“只要换成 Rust 写就一定快”其实不然。Rolldown 真正快的原因一半靠 Rust另一半靠它在架构上避开了过去那种“两套引擎各做一遍”的重复劳动。之前 Vite 开发要预构建生产要重新打包;现在 Rolldown 一套模块图从开发用到底该缓存的缓存该复用的复用浪费掉的做工少了时间自然下来了。2.2 兼容 Rollup 插件生态不是重新发明一套当时很多人担心Rolldown 出来Rollup 那几千个插件是不是全废了Vite 8 给出的答案是不会Rolldown 在插件 API 层面做了兼容层大多数 Rollup 插件不需要改代码就能跑。这一点非常重要。生态是 Vite 的护城河社区里积累了大量好用的 Rollup 插件比如rollup-plugin-visualizer、vite-plugin-compression如果换引擎意味着这些全部需要重写那升级成本谁都承受不起。Rolldown 采用的做法是实现 Rollup 的插件钩子协议让插件作者无感迁移。它能做到这一点本质上是因为它在一开始设计时就盯准了 Rollup 的输出模型和钩子机制而不是自己另搞一套虽然这带来了很大的实现工程量。我在实际迁移中确实感受到这一点项目里用了十几个插件真正需要改配置的不到三个。剩下的大多只是需要升级到支持 Rolldown 的新版本。2.3 换芯后的统一模型Vite 8 里Rolldown 同时承担了原来 esbuild 和 Rollup 两份工作开发服务器的依赖预构建Rolldown 做但底层换成了 Rust 实现速度更快。生产打包Rolldown 做但插件体系兼容 Rollup。源码 transformRolldown 内部集成了对 TS/TSX/JSX 的转译能力基于 Oxc 的 transformer不再单独依赖 esbuild。CSS、静态资源、代码分割、产物优化全部走 Rolldown 的单一路径。也就是说不管开发还是生产模块从入口到产物全程只经过一遍处理。两个引擎之间的行为差异问题从根上消失了。3. 实测全程从 Vite 7 升到 Vite 8 怎么换芯理论说再多不如直接上手跑一遍。下面是我这次升级的完整实操记录。3.1 升级步骤与依赖版本检查我的测试项目技术栈是 Vue 3 TypeScript Vite300 多个页面路由node_modules 解压后 2GB 左右算是比较典型的中大型公司内部中后台项目。升级流程其实不复杂但有几个前置检查必须做。第一步确认 Node.js 版本。Vite 8 要求 Node.js 20.19 或者 22.12如果你的项目还在用 Node 18必须先升级 Node。我这边直接切到 Node 22 LTS。第二步升级 Vite 相关依赖。我在 package.json 里做了如下调整{ devDependencies: { vitejs/plugin-vue: ^6.0.0, vitejs/plugin-react: ^5.0.0, vite: ^8.0.0, vite-plugin-compression: ^0.5.2, rollup-plugin-visualizer: ^5.14.0 } }注意vitejs/plugin-vue和vitejs/plugin-react这两个官方插件必须升级到支持 Vite 8 的版本老版本直接跑会报 hook 不兼容的错误。运行npm update后观察一下依赖树确认没有因为版本冲突被锁在老版本上。第三步检查第三方 Vite 插件。我是这样做的打开 package.json把带vite-plugin和rollup-plugin前缀的包全部过一遍逐一去 npm 页面看 README 里有没有写“支持 Vite 8 / Rolldown”。不支持的先暂时禁用确认项目能跑起来再逐个放回来排查。3.2 配置迁移那些需要改的和需要删的Vite 8 对配置 API 做了一些调整很多原来必须写的兼容配置现在可以删掉了。我重点处理了这几块移除 esbuild 专项配置以前 Vite 配置里如果有esbuild字段比如自定义esbuild.jsxInject、esbuild.target在 Vite 8 里这些会直接失效或报警告因为 esbuild 不再负责源码转译了。我从配置里删掉了// 旧配置Vite 8 中不再生效建议删除 esbuild: { jsxInject: import React from react, target: es2020 }如果项目里有 JSX 注入需求Vite 8 里用的是 Oxc 的对应配置oxc字段不过大多数场景下官方插件已经处理好了不太需要手动配置。检查 optimizeDeps 配置optimizeDeps配置比如include、exclude在 Rolldown 引擎下也还有效但这个配置的职责延续自 esbuild 时代Rolldown 下个别包的预构建行为有变化。我项目里原本optimizeDeps.include手工添加了十来个包升级后实测发现大部分其实已经不需要了Rolldown 的依赖处理比 esbuild 更智能能自动处理更多 CJS 依赖。我的建议是升级后保留原配置先跑通然后把 include 列表一项一项移除测试确认移除后开发服务能正常启动、页面不报错再删。这样最稳。Rollup 配置项的处理build.rollupOptions这个配置入口在 Vite 8 里仍然保留用来兼容 Rollup 的配置习惯。但底层是 Rolldown 在执行所以像output.manualChunks、output.chunkFileNames这些常见选项都能用行为上也基本保持了一致。不过有个重要变化纯 Rollup 插件的部分 API 能力有差异尤其是那些直接操作产物的钩子比如renderChunk、generateBundleRolldown 支持度已经很高了但如果你用到的是非常冷门的 hook 组合建议升级后在 CI 里跑一遍完整构建验证。CSS 处理差异这个算是我这次迁移中比较隐蔽的坑。原来项目里有一些针对 CSS 的 PostCSS 插件配置升级后发现某个样式在产物里少了一段。排查后发现是 PostCSS 插件的执行时机在 Rolldown 下和原来不一样导致处理顺序变化。解决方式是改为在 CSS 插件里显式声明postcss配置而不是依赖默认执行顺序。3.3 实测数据构建快了 3.19 倍是怎么测出来的先声明一下3.19 倍这个数据来自我这次测试的项目不同项目规模、依赖复杂度、硬件环境都会影响具体数字。但方向是一致且确定的Rolldown 下构建时间大幅下降。我的测试环境MacBook Pro M1 Pro 16GBNode.js 22.15.0项目跑在本地磁盘SSD。指标Vite 7esbuild RollupVite 8Rolldown提升倍数生产构建总耗时127.3 秒39.8 秒3.19 倍冷启动开发服务器3.8 秒1.1 秒3.45 倍依赖预构建时间28.6 秒7.4 秒3.86 倍构建峰值内存Node 侧3.7 GB2.8 GB降低 24%产物总大小12.4 MB12.1 MB基本持平生产构建我连续跑了三次取中位数保证数据不是偶然波动。手动执行命令是这样的npm run build为了更精确地看时间我用了time命令加精细计时time npx vite build标准输出的最后一行会显示✓ built in 39.8s配合系统 time 一起看。构建峰值内存怎么看的我用了node --max-old-space-size4096跑构建然后观察--trace-gc输出的堆统计同时用系统自带的 Activity Monitor 监控进程 RSS。Vite 7 时代同样项目偶尔会撞到 Node 内存上限需要调大--max-old-space-size;Vite 8 下构建过程内存曲线平稳很多没有再出现 OOM 风险。冷启动提升的体感冷启动从 3.8 秒到 1.1 秒这个提升体感比数据更明显。原来的项目因为依赖多每次npm run dev启动都要等 esbuild 预构建一遍几百个包期间页面白屏。现在 Rolldown 的预构建明显更快而且有增量缓存机制第二次启动基本是秒开。要注意的是增量缓存依赖node_modules/.vite目录如果 CI 环境每次都是干净构建、直接清掉这个缓存目录那第一个人的“冷启动速度”会慢一些但从第二个增量开始会很快。如果你在 CI 里也想享受这个加速可以把.vite目录放进缓存。生产构建为什么提升最大生产构建从 127 秒降到 39.8 秒提升最大原因不复杂。以前 Vite 7 生产构建是先用 esbuild 预构建依赖这 28 秒就是它花的再用 Rollup 全量打包另一个 90 多秒。两套引擎是两个独立过程各有各的开销。Rolldown 一套引擎同时搞定预构建和打包原来重复解析依赖的浪费就没了。还有一点Rolldown 对多核 CPU 的利用更好。我没做严格测试但观察 CPU 活动监视器可以看到Vite 7 构建时 CPU 使用率会有明显的一段一段的串行波动Vite 8 构建时多核使用更均匀。对 CI 上使用的机器核数越多提升幅度越明显。4. 常见问题与排查技巧实录升级过程中遇到了不少问题我把典型的几个整理出来按问题现象、排查思路、最终解法列成速查表方便你对照。问题现象可能原因解决方案控制台报The xxx hook is not supported by Rolldown使用的 Rollup 插件调用了 Rolldown 尚未支持的 hook查看插件是否有新版本暂时禁用该插件替换为替代插件开发正常生产构建产物里某些 chunk 变成空文件插件访问了 Rolldown 下不同的模块图状态检查自定义插件中transform、resolveId的返回值对照 Rollup 和 Rolldown 的 hook 行为差异Cannot find module esbuild或相关警告项目里某些工具链依赖仍硬编码引用 esbuild安装esbuild作为显式 devDependency 以兼容长期建议升级该工具链升级后构建产物 hash 全部变化CI 缓存全部失效打包行为变化导致产物文件名不同这是预期行为保留旧的缓存清理策略发布时清一次缓存即可构建内存不降反升某些插件在 Rolldown 下内存占用异常使用vite build --debug查看插件耗时与内存定位到具体插件后做降级处理PostCSS 处理顺序异常样式丢失Rolldown 下 PostCSS 与 CSS 插件执行时机变化在 CSS 相关插件中显式声明postcss配置或使用postcss.config.js统一管理4.1 插件兼容性最常见的三种报错第一种报错最直接The renderStart hook is not supported by Rolldown这种。看到这个说明你项目里有插件用到了 Rolldown 还没实现的 hook。处理方式很简单先去插件仓库看看有没有发新版如果维护不活跃就找替代方案。第二种是插件能在 Rollup 下跑、在 Rolldown 下却输出错误产物。这类问题最费时间因为它不报错业务上很难察觉。我的排查思路是先用git stash减掉一半插件跑构建看问题是否复现用二分法定位到具体插件。第三种是 CJS 依赖解析变化。esbuild 做依赖预构建时有个interop处理逻辑Rolldown 的实现方式不一样导致某些包在升级后导入方式需要调整。最典型的报错是The requested module xxx does not provide an export named yyy。碰到这个先在optimizeDeps.include里强制包含试一下不行就在代码里改成默认导入再解构。4.2 产物行为差异hash、分包、资源引用规则升级后第一次构建你要有心理准备产物的 hash 几乎是全部变掉的。这不一定代表资源内容变了只是因为打包引擎换了文件名策略有些微差异。对用户无感知但对 CI 缓存策略有影响。我建议你升级当天的发布流程里手动把 CDN 上的旧版本缓存清一遍避免新旧资源混用。另外分包规则也要注意。原来 Rollup 下通过manualChunks手工分割出来的 chunk在 Rolldown 下可能分裂或合并的方式不一样。比较稳妥的做法是升级后先不优化manualChunks让 Rolldown 用自己的默认分包策略跑一遍看产物大小和请求数量是否可接受再决定是否手动干预。4.3 开发体验里的隐藏变化有几个变化不体现在 benchmark 数字里但对日常开发影响不小。热更新HMR在 Rolldown 下的体验更稳定了。以前项目大一点改一个底层模块会连锁触发大量模块刷新页面偶尔闪一下。Rolldown 的依赖图是增量维护的HMR 链路更精确刷新范围明显小了很多。还有一个点是 sourcemap。Vite 8 下 sourcemap 的生成速度也快了不少调试体验更贴近“开发即生产”。我用--sourcemap跑过一次构建完整生成 sourcemap 的总耗时比 Vite 7 少了约 60%这对线上排查问题很有价值。5. 升级前必须知道的取舍与避坑清单最后把这几天折腾下来总结的最关键经验直接甩出来升级前务必过一遍。这些情况建议立即升级项目构建时间超过 60 秒团队日常被 CI 等待折磨的。项目依赖很多开发冷启动超过 5 秒的。遇到过 esbuild 和 Rollup 行为不一致导致线上 bug 的。这些情况建议等等项目里用了一些很冷门的 Rollup 插件且插件作者已经很久没维护的。项目对产物有非常严格的自定义要求比如定制化分包策略、特殊资源处理管线需要提前验证 Rolldown 是否完全满足。团队正在忙上线没有时间处理升级带来的潜在回归风险。这种时候建议等一个 patch 版本稳定后再动。我的几个实操心得升级前先建一个 feature 分支把 Vite 7 的node_modules整体备份一份直接复制文件夹或者用npm ci锁定 lockfile出问题随时回滚成本极低。在 CI 里增加一条定时任务跑一遍vite build --mode production并对比构建产物的大小和数量。这样升级后即使没有开发同学主动发现风险也能被自动化盯住。vite build --debug这个命令在排查插件性能问题时有奇效。它会输出每个插件的 hook 耗时明细一眼就能看出哪个插件在 Rolldown 下成了性能瓶颈。我个人在实际操作中的一个体会是Vite 8 这次换芯给我最大的惊喜不是单纯的构建变快而是“开发环境越来越接近生产环境”这件事终于从口号变成了现实。以前两套引擎各自为政很多问题只会在生产构建里暴露现在引擎统一很多隐性问题在开发阶段就直接现形了。这个价值比省下那几分钟 CI 时间更值钱。最后再分享一个小技巧升级完 Vite 8 后项目里的tsconfig.json里moduleResolution建议保持bundler模式如果之前用的是node模式趁这次升级一起改成bundler。Rolldown 对 ESM 的解析更标准bundler模式能让类型检查结果和实际构建行为更一致减少“构建能过、类型报错”的错位感。这次升级从开始动手到完全稳定花了我大概一个周末的时间。如果你项目比我这个更复杂建议留出两到三天的缓冲期。整体方向我很看好Vite 8 这一版值得升。