Vite 8 换上 Rolldown 后，前端构建真的会快很多吗？

Vite 项目写到后期，最容易让人烦的不是 dev server 起不来，而是每次 npm run build 都像在等一锅水烧开。

Vite 8 最大的变化，就是把生产构建底层换成了 Rolldown。官方说它是统一的 Rust bundler，目标是让构建速度明显快起来。但这类性能数字不能只看发布公告，最好拿自己的项目跑一遍。

这篇不做新闻复述，我们直接看：Vite 8 改了什么、怎么升级、怎么测构建耗时，以及哪些项目要先慢一点。

Vite 8 到底换了什么

以前 Vite 是两套打包链路一起干活：

开发阶段主要靠 esbuild，负责依赖预构建、TypeScript / JSX 转换，所以 dev 体验很快；
生产构建主要靠 Rollup，负责 bundle、chunk、tree shaking 和插件生态。

这个设计撑了很多年，也确实好用。但它的问题也很明显：开发和生产不是同一条管线，插件、模块解析、转换行为都需要 Vite 在中间做大量协调。

Vite 8 的方向是把这件事收回来：用 Rolldown 作为统一的 Rust bundler。Rolldown 的目标不是做一个完全陌生的新工具，而是尽量兼容 Rollup / Vite 的插件 API，同时把打包性能拉上去。

官方公告里提到几个重点：

Vite 8 使用 Rolldown 作为单一的 Rust bundler；
官方基准里，Rolldown 相比 Rollup 有 10-30 倍的性能提升空间；
多家公司在预览阶段反馈了生产构建耗时下降；
Vite 8 仍然要求 Node.js 20.19+ 或 22.12+；
@vitejs/plugin-react v6 移除了 Babel 默认依赖，React Refresh 转换改用 Oxc。

这里有两个信息要分开看。

一个是「方向很明确」：Vite 在把构建链路往 Rust / Oxc / Rolldown 这套工具链上收拢。

另一个是「你的项目不一定立刻快 30 倍」：真实收益取决于项目规模、插件数量、Babel 使用情况、CSS 处理、产物拆包策略和 CI 环境。

所以升级前，我不会直接把版本号一改就合并，而是先建一个分支跑完整检查。

先确认项目能不能升级

第一步不是改 package.json，而是看 Node 版本。

bash 复制代码

node -v

如果低于 Node.js 20.19，先别动 Vite。CI、Dockerfile、本地开发机都要一起升，不然你本地能跑，线上构建环境可能直接挂。

接着看项目现在用的 Vite 和插件版本：

bash 复制代码

npm ls vite @vitejs/plugin-react

如果是 pnpm：

bash 复制代码

pnpm list vite @vitejs/plugin-react

然后开一个干净分支：

bash 复制代码

git checkout -b chore/try-vite-8-rolldown

升级依赖：

bash 复制代码

npm i -D vite@latest @vitejs/plugin-react@latest

如果你的 React 项目依赖 Babel 插件，比如用了 React Compiler、自定义宏、装饰器转换，别只盯着 vite。@vitejs/plugin-react v6 默认不再把 Babel 当作基础依赖，这类项目要单独确认 Babel 链路有没有被你显式配置。

先跑一次构建：

bash 复制代码

npm run build

能过只是第一关。下一步才是看它到底快不快。

用脚本测，不要凭感觉

构建耗时最怕凭感觉。第一次跑可能有缓存，第二次跑可能机器负载不一样，CI 上又是另一套环境。

我一般会在项目根目录临时放一个脚本，跑 3 次构建，取平均值。

javascript 复制代码

// bench-build.mjs
import { spawnSync } from "node:child_process";
import { rmSync } from "node:fs";
import { performance } from "node:perf_hooks";

const runs = Number(process.env.RUNS ?? 3);
const times = [];

for (let i = 1; i <= runs; i += 1) {
  rmSync("dist", { recursive: true, force: true });
  rmSync("node_modules/.vite", { recursive: true, force: true });

  const start = performance.now();
  const result = spawnSync("npm", ["run", "build"], {
    stdio: "inherit",
    shell: process.platform === "win32",
  });
  const end = performance.now();

  if (result.status !== 0) {
    process.exit(result.status ?? 1);
  }

  const seconds = (end - start) / 1000;
  times.push(seconds);
  console.log(`run ${i}: ${seconds.toFixed(2)}s`);
}

const average = times.reduce((sum, time) => sum + time, 0) / times.length;
console.log(`average: ${average.toFixed(2)}s`);

运行：

bash 复制代码

node bench-build.mjs

如果要跑 5 次：

bash 复制代码

RUNS=5 node bench-build.mjs

Windows PowerShell 写法：

powershell 复制代码

$env:RUNS=5; node bench-build.mjs

对比时至少跑两组：

bash 复制代码

# 老版本分支
node bench-build.mjs

# Vite 8 分支
node bench-build.mjs

这里不要只看平均耗时，还要顺手看三件事：

dist/ 产物体积有没有明显变化；
chunk 拆分名称和数量有没有变得离谱；
构建日志里有没有 plugin warning 或 deprecated warning。

如果项目有预览命令，再跑一遍：

bash 复制代码

npm run preview

只看 build 通过不够。至少打开几个核心页面，确认路由、懒加载、样式、静态资源路径都正常。

哪些项目最可能吃到红利

如果你的项目满足这些条件，Vite 8 的收益通常更值得期待：

页面和组件数量多，生产构建时间已经明显偏长；
rollupOptions 配置不算特别魔改；
插件主要来自主流生态，比如 React、Vue、Svelte、UnoCSS、Tailwind；
CI 构建时间是团队真实痛点；
没有大量依赖自定义 Babel 插件。

这类项目可以先拿一个业务分支试跑。哪怕只快了 30%-50%，在每天多次 CI 构建的团队里也很明显。

但如果你的项目很小，原来 build 只要 2 秒，升级之后从 2 秒变成 1 秒，体感不会强。你真正关心的反而是兼容性和包体变化。

还有一类项目要谨慎：构建配置很复杂、自己写了 Vite / Rollup 插件、依赖老 Babel 插件、或者 SSR 逻辑比较重。

Rolldown 尽量兼容 Rollup 插件 API，但「尽量兼容」不等于「所有边角行为完全一样」。越靠近 bundler 底层的插件，越应该单独验证。

我会重点查这 5 个坑

1. Node 版本

这最容易被忽略。Vite 8 需要 Node.js 20.19+ 或 22.12+。本地、CI、Docker 镜像、部署平台，都要对齐。

2. React 插件里的 Babel 依赖

@vitejs/plugin-react v6 默认不再依赖 Babel。如果你的项目只是普通 React Refresh，多半没事。

但如果你在 babel 选项里塞了插件，或者依赖 React Compiler，就要按新方式显式接入，不要默认以为旧配置还能原样工作。

3. 自定义 Rollup 插件

项目里如果有这种配置，优先检查：

typescript 复制代码

// vite.config.ts
export default {
  build: {
    rollupOptions: {
      plugins: [
        // 自定义插件
      ],
    },
  },
};

尤其是用了 transform、generateBundle、renderChunk、moduleParsed 这些 hook 的插件，升级后要用真实业务页面验证产物。

4. CSS 和静态资源

Vite 8 把 lightningcss 作为正常依赖，用来提供更好的 CSS minification。官方也提到 Vite 8 自身体积比 Vite 7 大约多 15 MB，其中一部分来自 lightningcss。

这不一定是坏事，但你要看构建后的 CSS 是否符合预期，特别是用了 CSS Modules、PostCSS 插件、老浏览器兼容配置的项目。

5. Agent 工作流

Vite 8 有一个对 AI coding agent 很友好的变化：可以把浏览器里的 console log 和 error 转发到 dev server 终端。

这意味着 Codex、Claude Code 这类工具在本地跑项目时，不一定非要接浏览器调试协议，光看终端就能发现一部分前端运行时报错。

如果你的团队已经在让 AI 改前端代码，这个能力很实用。以前 agent 只知道 npm run dev 没挂，现在至少能看到页面运行时有没有炸。

我的升级建议

新项目可以直接用 Vite 8。它已经是稳定版本，默认工具链也更清爽。

老项目别急着一把梭。我会按这个顺序来：

升 Node 和 CI 镜像；
开分支升级 Vite 8；
跑 npm run build、npm run test、npm run preview；
用 bench-build.mjs 跑 3-5 次构建耗时；
检查 dist/ 体积、chunk 数量、关键页面；
如果用了自定义插件，单独做一次插件兼容检查；
对比收益和风险，再决定要不要合并。

如果项目够复杂，也可以先在 Vite 7 上试 rolldown-vite，把 bundler 变化和 Vite 主版本变化拆开看。这样出了问题更容易定位：到底是 Rolldown 兼容问题，还是 Vite 8 本身的破坏性变化。

结尾

Vite 8 值得升，但不要只拿官方性能数字做决策；真正靠谱的做法，是把它放进你自己的项目、自己的 CI、自己的插件组合里跑一遍。

你现在的前端项目，npm run build 一次大概要多久？如果已经超过 1 分钟，我会优先拿它试 Vite 8。

资源链接：

Vite 8 官方公告：vite.dev/blog/announ...

Vite Rolldown 文档：vite.dev/guide/rolld...

Vite 插件注册表：registry.vite.dev

Rolldown 官网：rolldown.rs