编程 Vite 8 深度拆解：当 Rust 打包器 Rolldown 成为默认引擎——统一工具链、10-30 倍提速与前端构建新范式

2026-07-17 00:18:32 +0800 CST views 9

Vite 8 深度拆解：当 Rust 打包器 Rolldown 成为默认引擎——统一工具链、10–30 倍提速与前端构建新范式

本文面向有构建工具使用经验的工程师。我们会从「为什么需要 Rolldown」这个根本问题出发，逐层拆解 Vite 8 的架构演进、Rolldown 的核心机制、真实可落地的迁移实战、性能调优方法论，以及它对前端生态的长期影响。读完你应该能回答两个问题：Vite 8 到底改了什么？以及，我的项目现在该不该升？

一、背景：从「双引擎」到「单一真相」

Vite 自 2021 年发布以来，底层一直是一套「分裂」的策略：开发服务器（dev server）用 esbuild 做依赖预构建和 TS/JSX 转译，生产构建（build）则用 Rollup 做打包。这套组合在很长一段时间里是工程权衡的结果——esbuild 用 Go 编写、冷启动极快，适合开发态；Rollup 生态成熟、Tree Shaking 精准，适合产线。它确实让 Vite 在「快」和「对」之间找到了一个足够好的平衡点，从而迅速成为前端构建工具的事实标准，连 Vue、Nuxt、SvelteKit、Astro、Vitest 都把它当底座。

但分裂是有代价的，而且这个代价是结构性的。最经典的抱怨就是那句：「dev 跑得好好的，build 就挂了」。根因往往在于 esbuild 与 Rollup 对同一语法的转译 / 解析语义并不完全一致：

对 import.meta.env 的注入时机与取值；
对 top-level await 的兼容性边界；
对 CSS 中 @import 的解析与合并顺序；
对 JSON 模块的导出方式（具名导出 vs 默认导出）；
对 CommonJS / ESM 互操作（interop）的默认处理。

开发态用 esbuild 通过了，生产态 Rollup 却报错；或者反过来，本地没问题、CI 上构建挂。这类「环境不一致」问题没有技术含量，却消耗了大量前端工程师的排障精力——而它本不该存在。

2026 年 5 月 7 日，由 Evan You（尤雨溪）创立的 VoidZero 正式发布 Rolldown 1.0——一个用 Rust 编写、兼容 Rollup 插件 API、性能对标 esbuild 的 JavaScript/TS 打包器。距离它最初公开亮相，正好两年。仅仅数周后，Vite 8 的首个 Beta 将 Rolldown 设为默认打包器，彻底终结了「Dev ≠ Prod」的时代。

关键数据：Rolldown 比 Rollup 快 10–30 倍，与 esbuild 性能持平。真实代码库基准里，PayFit 的复杂前端构建从 120 秒降至 8 秒（15×），Linear 从 46 秒降至 6 秒。Rolldown 周下载量已突破 2000 万。

这不是一次普通的版本升级，而是前端构建工具「Rust 化」浪潮的集大成者。事实上，过去三年整个前端工具链都在悄悄换底层：

Babel（JS）→ SWC（Rust），转译提速一个数量级；
Terser（JS）→ esbuild / oxc-minify（Rust / Go），压缩更快；
webpack（JS）→ Turbopack（Rust，Next.js 内置）/ Rspack（Rust，字节跳动）；
Rollup（JS）→ Rolldown（Rust，VoidZero）。

Vite 8 的意义在于，它把这些「点状替换」收口成了一条统一的、全 Rust 的构建流水线——解析、转换、打包、压缩第一次跑在同一个内核上。

二、核心概念：Rolldown 到底是什么

2.1 一句话定义

Rolldown 是一个用 Rust 编写的 JavaScript/TypeScript 打包器，它的对外契约是「Rollup 兼容的 API + 插件接口」，但内部实现更接近 esbuild——单遍、多线程、原生速度。

这带来两个直接结论：

你现有的绝大多数 Rollup 插件在 Rolldown 上开箱即用；
你获得的是接近 esbuild 的构建速度，而不是 Rollup 的 JS 单线程速度。

换句话说，Rolldown 同时拿下了 esbuild 的「快」和 Rollup 的「生态兼容性」——这正是它最聪明的地方。它没有逼用户在「快但封闭」和「慢但开放」之间二选一。

2.2 为什么不是「直接用 esbuild」

很多人会问：既然 esbuild 已经够快，为什么不直接把 esbuild 当默认打包器？

答案在可扩展性与生态连续性：

esbuild 的插件系统是「封闭」的。为了极致速度，它牺牲了对 bundling 过程的细粒度介入能力——很多 Rollup 插件赖以生存的钩子（如 renderChunk、generateBundle、resolveId 的复杂语义、对 chunk 输出的后处理）esbuild 并不提供。这意味着一旦你依赖了这类插件，esbuild 就无法完全替代 Rollup。
Rolldown 选择把 Rust 的速度和 Rollup 的插件语义同时拿下，并进一步解锁了 Rollup 因 JS 性能所限而做不了的高级特性（全量打包模式、模块级持久缓存、原生模块联邦）。

所以 Rolldown 的定位不是「又一个 esbuild」，而是「一个能跑出 esbuild 速度的 Rollup」。对存量数百万 Rollup 项目来说，这个定位意味着迁移成本趋近于零——这是它相比「再造一个 esbuild」更聪明的工程判断。

2.3 与 Oxc 的深度协同

Rolldown 不是孤军奋战。VoidZero 旗下还有 Oxc——一个同样用 Rust 编写的「高性能 JS/TS 工具链」，包含 parser、transformer、linter、resolver。在 Vite 8 的统一架构中，四者分工如下：

解析（resolve）：由 Oxc resolver 承担；
转换（transform）：由 Oxc transform 承担，替代 Babel / esbuild 的转译；
打包（bundle）：由 Rolldown 承担；
压缩（minify）：由 Oxc minifier 承担。

它们都用 Rust 实现，通过 napi-rs 暴露 Node 绑定，并共享同一套 AST 表示与内部数据模型。这正是 Vite 8 能把「解析—转换—打包—压缩」串成同一条流水线的根本原因：dev 和 build 跑的是同一套 Rust 内核，而不是两个语言、两套逻辑。

这里值得展开讲一下 napi-rs 这层绑定。Rolldown 的本体是 Rust 编译出的 .node 原生模块，Node 通过 napi-rs 生成的胶水代码调用它。调用原生模块有一次跨越 JS / Rust 边界的序列化成本，但 Rolldown 的设计是把「整个打包过程」放在 Rust 侧一次完成，只把最终结果（bundle 字符串、sourcemap）传回 JS——而不是每个模块都来回跨边界。这把边界成本摊薄到了几乎可忽略，是它能在 Node 生态里保持原生速度的关键技巧。

2.4 三大新能力

Rolldown 为 Vite 解锁了此前 Rollup 难以企及的能力：

Full Bundle Mode（全量打包模式）：从入口到依赖做一次完整打包，优化模块合并与 Tree Shaking 效率，对超大单体应用收益明显。
模块级持久缓存（Module-level Persistent Cache）：按模块内容哈希缓存产物，二次构建只重建真正变更的模块。
原生模块联邦（Module Federation）：不再依赖 @module-federation/vite 这类社区插件，Rolldown 在核心层支持远程模块的动态加载，微前端架构的运行时开销更低。

2.5 为什么 Rust 能做到「又快又兼容」

一个常见的误解是：Rust 比 JS 快，所以 Rolldown 快。这没错但不够。真正的关键是三点叠加：

语言层：Rust 编译为原生机器码，无 GC 停顿、无 JS 单线程瓶颈；
并行层：模块解析、转译、Tree Shaking 是多核并行，而非 Node 的单线程事件循环；
架构层：解析 / 转换 / 打包共享同一 AST，避免 Rollup「每过一个插件就序列化 / 反序列化一次 AST」的重复开销。

而「兼容」则靠 Rolldown 在 Rust 侧完整实现了 Rollup 的插件钩子语义——它把 resolveId、load、transform、renderChunk 等钩子的调用时序、参数形状、返回值约定都对齐到 Rollup 规范，让插件作者感觉不到底层换了引擎。这是 Rolldown 工程量最大、也最有价值的一部分。

三、架构分析：双引擎 → 单引擎

3.1 Vite 7 及以前的架构

开发：  浏览器 ← HMR ← Vite Dev Server（esbuild 预构建 + 原生 ESM）
生产：  源码 → Rollup（打包） → 产物

两套解析 / 转换 / 打包逻辑，语义不完全对齐。dev 用 esbuild 的 resolver 和 transformer，build 用 Rollup 的；两者的「真相」天然存在偏差。

此外，开发态还有一层 optimizeDeps（依赖预构建）——esbuild 把 node_modules 里的 CJS 依赖预先打包成 ESM，避免浏览器逐个请求成百上千个小文件。这层预构建与生产构建又是两套路径，进一步放大了不一致。于是开发者实际面对的是三套真相：dev 的 esbuild、dev 的 optimizeDeps、build 的 Rollup。

3.2 Vite 8 的架构

开发 & 生产：共享同一套 Oxc（resolve + transform）+ Rolldown（bundle + minify）

统一的直接收益：

行为一致性：import.meta.env、top-level await、CSS @import 顺序、JSON 导出在 dev 和 build 中表现完全一致，从根上消除「dev 过 build 挂」。
可观测性统一：同一套 sourcemap、同一套错误栈，调试体验一致；CI 上看到的报错和本地一致。
性能可对齐：开发态的模块图与生产态的模块图来自同一引擎，性能瓶颈可以端到端对齐分析，不再出现「本地秒开、CI 五分钟」。
依赖预构建统一：optimizeDeps 现在也走 Rolldown 的解析 / 转换路径，开发态与构建态对第三方依赖的处理完全一致。

3.3 Rolldown 内部 crate 结构

Rolldown 是一个 Rust workspace，核心 crate 大致如下：

crates/rolldown：打包主逻辑（模块图构建、作用域分析、Tree Shaking、代码生成）；
crates/rolldown_plugin：插件系统（Rollup 兼容钩子的 Rust 实现）；
crates/rolldown_utils：共享工具（哈希、字符串处理、并行调度）；
crates/rolldown_binding：Node.js 绑定层（napi-rs）。

Rust 的零成本抽象 + 内存安全，让 Rolldown 能在多线程并行解析 / 转换的同时，不必像 JS 那样担心数据竞争。它把模块图构建、转译、Tree Shaking 拆成可并行的任务，充分利用多核 CPU——这是它能在「保持 Rollup 插件语义」的同时还跑出 esbuild 级速度的根本原因。

3.4 模块图构建流水线

Rolldown 的核心流程可以抽象为四阶段：

入口分析 → 依赖图遍历（并行 resolve + transform）
        → 作用域与副作用分析（Tree Shaking）
        → chunk 划分与代码生成（并行）

其中「依赖图遍历」和「代码生成」都是天然可并行的——每个模块的 parse / transform 互不依赖，可以扔给线程池；「作用域分析」需要做跨模块的数据流分析，是 Rolldown 算法投入最重的部分，也是 Tree Shaking 准不准的关键。Rust 的所有权模型让这些并行任务之间的数据共享既安全又零锁竞争。

四、代码实战：从 Vite 7 迁移到 Vite 8

4.1 最小迁移

大多数项目零配置即可升级：

# 升级到下一个大版本
npm i -D vite@next
# 或显式锁定 8.x
npm i -D vite@^8

vite.config.ts 通常无需改动。只要你的项目只用了标准 plugin-vue / plugin-react 等主流插件，升级后 Rolldown 会自动接管打包：

// vite.config.ts —— Vite 8 下几乎不需要改动
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [vue()],
  // 不需要任何 build.rollupOptions 特殊配置，Rolldown 已是默认打包器
})

4.2 升级前 vs 升级后：一个对比示例

升级前（Vite 7，混合引擎、显式压缩配置）：

// vite.config.ts（Vite 7 常见写法）
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import terser from '@rollup/plugin-terser'

export default defineConfig({
  plugins: [vue()],
  build: {
    minify: 'terser',
    rollupOptions: {
      output: {
        manualChunks: { vendor: ['vue', 'pinia'] },
      },
    },
  },
})

升级后（Vite 8，Rolldown 默认、内置 minify）：

// vite.config.ts（Vite 8 推荐写法）
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [vue()],
  build: {
    // minify 默认即为 Rolldown 内置 oxc-minify，无需再装 terser
    rolldownOptions: {
      output: {
        manualChunks: { vendor: ['vue', 'pinia'] },
      },
    },
  },
})

可以看到：你移除了 @rollup/plugin-terser 依赖，把 rollupOptions 改名 rolldownOptions（语义一致），其余不动。这就是「零摩擦迁移」的含义。

4.3 显式用 Rolldown 独立打包（库打包场景）

Rolldown 也可以脱离 Vite 单独使用，API 与 Rollup 高度一致：

// rolldown.config.mjs
import { defineConfig } from 'rolldown'

export default defineConfig({
  input: 'src/index.ts',
  output: {
    file: 'dist/my-lib.mjs',
    format: 'esm',
    sourcemap: true,
  },
  // 内置 TypeScript / JSX 转换（来自 Oxc），无需再挂 @rollup/plugin-typescript
})

npx rolldown -c rolldown.config.mjs

注意：Rolldown 内置了 TS / JSX 转译，所以库打包场景下你不用再挂 @rollup/plugin-typescript 或 esbuild。这正是 Vite 8 的 build.lib 模式默认也改走 Rolldown 的原因——库的构建速度随之一起起飞。

4.4 Full Bundle Mode 实战

对超大应用，开启全量打包可减少 chunk 碎片、提升 Tree Shaking 命中率：

// vite.config.ts
import { defineConfig } from 'vite'

export default defineConfig({
  build: {
    rolldownOptions: {
      experimental: {
        fullBundleMode: true,
      },
    },
  },
})

4.5 原生模块联邦（微前端）

Vite 8 下，模块联邦不再依赖社区插件，核心层直接支持：

// host 应用 vite.config.ts
import { defineConfig } from 'vite'
import { moduleFederation } from 'vite/module-federation'

export default defineConfig({
  plugins: [
    moduleFederation({
      name: 'host',
      remotes: {
        cart: 'http://localhost:3001/assets/remoteEntry.js',
      },
      shared: ['react', 'react-dom'],
    }),
  ],
})

// 业务代码中像本地模块一样消费远程模块
const Cart = React.lazy(() => import('cart/CartWidget'))

4.6 兼容既有 Rollup 插件

绝大多数 Rollup 插件无需改动即可工作。若某个插件依赖 Rolldown 尚未 1:1 实现的钩子，可临时用 build.rollupOptions 兼容层兜底（过渡期）。Vite 团队的建议路径是：先跑通，再逐步移除冗余插件——比如你已经不再需要单独的 esbuild / terser 压缩插件，因为 Rolldown 内置 minify。

4.7 渐进式启用策略

对大型团队，推荐分四阶段落地：

第一阶段：直接升级 Vite 8，保持原有配置，验证构建产物与线上一致（重点比对 bundle 体积与运行时行为）；
第二阶段：移除冗余的 esbuild / terser 压缩配置，改用 Rolldown 内置 minify；
第三阶段：在 CI 中开启模块级持久缓存，二次构建时间进一步下降；
第四阶段：对微前端场景启用原生模块联邦。

4.8 踩坑与排障（实战经验）

升级到 Vite 8 后，常见需要关注的点：

CommonJS 互操作差异：Rolldown 对 CJS 默认导出的 interop 策略与 Rollup 略有不同。若遇到 require('x').default 取到 undefined，检查是否需要在 optimizeDeps 或 build.commonjsOptions 中调整 esmExternals / requireReturnsDefault。
top-level await：Rolldown 对 TLA 的支持更接近规范，但要求产物 format 为 esm 且 target 支持。若构建报 TLA 相关错误，确认输出格式与浏览器基线。
插件钩子未实现：个别深度定制插件可能用到 Rolldown 暂未实现的钩子，构建会给出明确警告。此时先回退该插件，或等待其官方适配版本。
CSS @import 顺序：统一引擎后，CSS 的 @import 合并顺序以规范为准，部分依赖「特定顺序 hack」的老代码可能需要微调。

一段实用的排障脚本，可以帮你在升级前后对比产物：

#!/usr/bin/env bash
# build-compare.sh —— 升级前后构建对比
set -e
rm -rf node_modules/.vite node_modules/.rolldown-cache dist
echo "==> 首次构建计时"
time npm run build
echo "==> 产物体积"
du -sh dist
echo "==> 二次构建计时（验证持久缓存）"
time npm run build

五、性能优化：让 10–30× 真正落到你项目上

5.1 真实基准（来自社区）

项目	旧（Rollup / 混合）	新（Rolldown）	提速
PayFit 复杂代码库	120s	8s	15×
Linear	46s	6s	~7.7×
通用中型 SPA	~30s	~3–5s	6–10×

重要提醒：提速幅度与项目特征强相关——依赖越多、模块图越大，Rolldown 的多线程并行收益越明显；纯少量模块的小项目收益有限。不要被「30×」的峰值误导，用你自己的项目测才有意义。

5.2 如何测量你自己的项目

在迁移前后各跑一次干净构建，并固定 Node 版本与机器负载（见 4.8 脚本）。对比三个数字：首次构建时间、二次构建时间、产物体积。Rolldown 的价值往往体现在「二次构建 + CI 缓存」的组合上，而不是单次冷构建。

5.3 模块级持久缓存调优

Rolldown 默认按模块内容哈希缓存。要让缓存命中率最大化：

固定依赖版本：用 package-lock.json / pnpm-lock.yaml 锁定，避免依赖 hash 漂移导致整片缓存失效；
拆分稳定模块：把变动频繁的「业务代码」与稳定的「第三方依赖」分到不同 chunk；
CI 缓存缓存目录：把 Rolldown 缓存目录纳入 CI 缓存，让「二次构建」跨流水线复用。

// vite.config.ts
export default defineConfig({
  build: {
    rolldownOptions: {
      cache: {
        enabled: true,
        directory: '.rolldown-cache', // 纳入 CI 缓存
      },
    },
  },
})

配合 GitHub Actions 的缓存步骤：

# .github/workflows/ci.yml（节选）
- name: Cache Rolldown
  uses: actions/cache@v4
  with:
    path: .rolldown-cache
    key: rolldown-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}
    restore-keys: |
      rolldown-${{ runner.os }}-

5.4 chunk 拆分策略

export default defineConfig({
  build: {
    rolldownOptions: {
      output: {
        manualChunks(id) {
          if (id.includes('node_modules')) {
            if (id.includes('monaco-editor')) return 'editor'
            if (id.includes('three')) return 'three'
            return 'vendor'
          }
        },
      },
    },
  },
})

合理的 manualChunks 能让持久缓存更稳定（改动业务代码不会让整个 vendor chunk 失效），同时改善首屏加载——这是「缓存命中率」与「首屏体积」之间的工程平衡。

5.5 与主流方案横向对比

维度	Rollup(JS)	esbuild(Go)	webpack	Turbopack(Rust,β)	Rolldown(Rust)
实现语言	JS	Go	JS	Rust	Rust
性能	基线	~10×	较慢	快	10–30×
插件生态	成熟	封闭	最成熟	早期	Rollup 兼容
Dev/Prod 一致	否	部分	否	是	是
模块联邦	需插件	否	原生	早期	原生

5.6 务实建议

不要盲目开启 Full Bundle Mode：它对超大应用有益，但对普通 SPA 可能增加单 chunk 体积、拖慢首屏，先用默认模式验证。
把持久缓存当头等公民：这是「二次构建」体验跃升的关键，尤其适合 monorepo 与 CI。
保留 sourcemap：Rust 工具链生成的 sourcemap 质量很高，配合 Sentry / 错误监控体系无压力，别为了省体积关掉它。
先量后优化：任何性能优化都从一次真实基准开始，不要凭感觉开开关。

六、生态影响：谁会被 Rolldown 改变

Vite 8 把 Rolldown 设为默认，影响的不只是直接用 Vite 的人，而是整个「Vite 系」生态：

Vitest：单元测试 / 组件测试的构建底座跟着换引擎，测试启动与转译更快；
Vite lib 模式：库作者用 build.lib 打包时直接享受 Rolldown 速度，无需再单独配 Rollup；
Nuxt / SvelteKit / Astro / Remix 等元框架：它们底层依赖 Vite，会间接获得一致性与性能收益；
微前端体系：原生模块联邦让 Module Federation 从「插件方案」变成「引擎能力」，运行时更轻；
Storybook / 文档站 / 脚手架：所有基于 Vite 的工具链都会跟着提速。

还有一个容易被忽视的连锁反应：构建变快会直接改变团队的开发习惯。当一次生产构建从两分钟降到十秒，工程师会更愿意频繁跑「完整构建 + 类型检查 + 产物审计」的预提交钩子，而不是只在_push_ 后等 CI 报错；本地也更敢做「改一行就重新全量验证」的快速迭代。工具的 latency 下降，往往带来工程纪律的提升——这不是玄学，而是反馈环路变短后的行为改变。

换句话说，Rolldown 不是 Vite 的「内部优化」，而是一次对前端构建底座的重新定义。它的「Rollup 兼容」决策，让这次底座替换对上游几乎无感——这正是它最可能快速普及的原因。

七、路线之争：Rolldown vs Turbopack vs Rspack

2026 年的前端打包器战场，Rust 派已经三分天下：

Turbopack（Vercel，Rust）：深度绑定 Next.js，强调「增量计算」与 dev 体验，生态偏私有、插件能力仍在早期；
Rspack（字节跳动，Rust）：兼容 webpack 配置与 loader，主打「webpack 用户零成本迁移」，企业市场强；
Rolldown（VoidZero，Rust）：兼容 Rollup 插件生态，主打「Rollup 用户零成本迁移 + esbuild 级速度」，社区与开源属性最强。

三者的共同选择是 Rust，共同痛点是「webpack / Rollup 的 JS 性能天花板」。分歧在「兼容谁」：Turbopack 兼容 Next、Rspack 兼容 webpack、Rolldown 兼容 Rollup。对绝大多数 Vite 用户而言，Rolldown 是「不用选」的那个——它随着 Vite 8 默认到来。

八、总结与展望

Vite 8 + Rolldown 的意义，远不止「构建快了 10 倍」。它代表前端工具链的一次范式收口：

Dev 与 Prod 的「单一真相」：同一引擎、同一语义，开发态即生产态，bug 不再在构建阶段「突然冒出来」。
Rust 工具链大一统：Oxc（解析 / 转译）+ Rolldown（打包）+ 各运行时，前端工程的「底层基础设施」正快速 Rust 化——正如后端世界曾经经历的 Go / Rust 化。
生态连续性优先：Rolldown 没有另起炉灶，而是选择「兼容 Rollup 插件 API」这个决策，让数百万现有项目能零摩擦迁移。这是它相比「再造一个 esbuild」更聪明的工程判断——技术先进性的前提是不砸掉用户的存量投资。
高级能力下沉到核心：模块联邦、全量打包、持久缓存从「社区插件」变为「引擎内置」，微前端、超大应用的架构成本被显著摊薄。

值得警惕的风险：

Vite 8 早期版本（截至 2026 年中）仍处于 Beta 向 Stable 过渡阶段，生产落地建议先在非核心业务灰度；
2026 年 5 月 TanStack 遭遇的供应链攻击（CVE-2026-45321，代号 Mini Shai-Hulud，CVSS 10.0）提醒我们：当工具链高度 Rust 化、依赖扁平化，供应链安全更需要 lockfile 审计与 SBOM 管控；
部分深度定制 Rollup 插件可能需要一段适配期，迁移前先盘点插件清单。

迁移建议：对绝大多数项目，升级 Vite 8 的成本接近于零（配置不变、插件兼容），收益是更快的 CI、更一致的 dev/build 体验。建议现在就把 vite@^8 纳入升级计划，先在预发环境跑通，再逐步推广到生产。

工具会变，但「让开发者少等一秒」的初心不变。Rolldown 不是终点，而是前端构建进入「原生速度 + 生态兼容」双螺旋时代的起点。当解析、转换、打包、压缩第一次跑在同一条 Rust 流水线上，我们失去的是「dev 和 build 两套真相」的长期焦虑，得到的，是整个前端工程效率的代际跃迁。

九、给你的迁移检查清单（可直接照做）

如果你决定现在就动手，下面这份清单可以作为团队内部的升级 PR 模板，逐条勾选即可：

盘点插件：列出 vite.config 里所有插件，确认是否都是 Rollup 兼容的主流插件；标记出任何自研 / 深度定制插件，提前查它们的 Rolldown 适配状态。
锁版本：升级前提交并锁定 lockfile，保证可回滚；建议用 vite@^8 而不是 vite@next，避免自动吃到未预期的预发布。
跑基准：用 4.8 的脚本在升级前后各测一次「首次构建 / 二次构建 / 产物体积」，把数字贴进 PR 描述，作为升级收益的证据。
比产物：把新旧 dist 各起一个静态服务，做一次冒烟测试，重点验证动态 import、import.meta.env、CSS @import、JSON 导入这四类最容易出不一致的点。
去冗余：确认构建通过且行为一致后，移除 @rollup/plugin-terser 等冗余压缩插件，改用 Rolldown 内置 minify。
开缓存：在 CI 中配置 .rolldown-cache 缓存（见 5.3），让二次构建的收益在流水线里落地。
灰度发布：先在一个非核心业务或内部工具上升级观察一周，再推广到核心应用；遇到插件钩子未实现的明确警告，先回退该插件并提 issue。

这套清单的核心思想只有一句：用数据驱动升级，而不是用信仰驱动升级。Rolldown 的快是真实的，但「你的项目快多少」只能由你自己的基准回答。

参考来源：Vite 官方博客（Vite 8 Beta 公告）、VoidZero / Rolldown 1.0 发布说明、社区基准（PayFit、Linear 构建提速数据）。本文配置示例为代表性示意，具体 API 名称与字段以你所使用的 Vite 8 / Rolldown 正式版文档为准。