Vite 8 为什么统一使用 Rolldown：开发构建与生产打包边界

升级 Vite 8 时，最容易误判的是“换了一个 bundler，所以所有配置都要重写”。实际变化更有边界：Vite 8 把原来由 esbuild 负责的依赖预构建和由 Rollup 负责的生产打包，收敛到 Rust bundler Rolldown；JavaScript 转换与压缩、CSS 压缩则分别落在 Oxc 和 Lightning CSS。先按职责核对，再决定哪些配置需要迁移，通常比直接删掉旧配置稳妥。

Vite 8 的核心不是让开发服务器和生产构建变成同一种运行模式，而是让两条打包与转换链使用更一致的底层能力；旧配置多数有兼容转换，但插件和切包策略仍要单独复查。

Vite 8 解决了哪条双打包链边界

过去的 Vite 把开发体验和生产结果交给不同工具：esbuild 擅长依赖预构建以及 TypeScript、JSX 转换，Rollup 负责生产打包、分块和插件扩展。两条链各有优势，但同一个模块可能经历两套解析、转换和插件协作，修复一边的边界问题，另一边不一定同步。

Vite 8 的结构变化可以先记成一句话：Vite 8 以 Rolldown 为统一 bundler，减少开发与生产之间的胶水逻辑。这里的“统一”不等于开发服务器马上默认启用 Full Bundle Mode；它首先统一底层打包能力，开发模式仍有自己的加载与 HMR 体验。官方发布说明把 Full Bundle Mode 作为后续实验方向，不能当成 Vite 8 的默认行为。

图中的开发链、生产链和统一工具链是静态职责分组：esbuild 与 Rollup 代表历史分工，Rolldown、Oxc、Lightning CSS 代表 Vite 8 的协作边界，Vite 8 负责把这些能力组织到同一套工程入口。

Rolldown、Oxc 与 Lightning CSS 如何分工

升级排查时不要只搜“Rolldown”，而要把工作拆开。依赖优化现在使用 Rolldown；JavaScript 转换从 esbuild 转向 Oxc；JavaScript 压缩默认使用 Oxc Minifier；CSS 压缩默认使用 Lightning CSS。它们处在不同层，故障现象也不同：依赖入口异常先看优化配置，语法转换异常看 Oxc，样式兼容或压缩差异看 Lightning CSS。

这个分层也解释了为什么“构建更快”不能直接等同于“所有项目都无需验证”。官方给出的 10–30 倍是基准和项目案例层面的表述，真实收益取决于模块规模、插件和资源处理方式。生产项目应记录原构建耗时、产物体积和异常日志，再做前后对比。

升级时哪些配置仍能自动转换

Vite 8 提供兼容层，很多项目可以先不改配置就完成升级。第一项检查是 Node.js：官方要求为 20.19+ 或 22.12+，这是 ESM 分发和 require(esm) 行为的基础。版本不满足时，先升级运行环境，不要把报错误判为 Rolldown 插件问题。

第二项检查是依赖优化。旧的 optimizeDeps.esbuildOptions 仍可被自动转换到 optimizeDeps.rolldownOptions，但它已进入弃用路径。可以把迁移记录写成一张小表：minify 对应 output.minify，treeShaking 对应 treeshake，define 对应 transform.define；不确定的字段不要凭名字猜，回到迁移文档逐项核对。

export default defineConfig({
  optimizeDeps: {
    rolldownOptions: {
      output: { minify: true }
    }
  }
})

第三项检查是 build.rollupOptions。它仍能帮助旧项目平滑过渡，但官方已经把 build.rolldownOptions 作为新的命名方向。迁移时建议一次只改一类设置：先升级并完成构建，再迁移依赖优化，最后处理输出和插件相关配置。这样每次失败都有明确的回退点。

插件与切包边界要怎么复查

大多数 Vite 插件继续依赖 Rollup/Vite 插件 API，因此不必看到 Rolldown 就全部替换。真正值得单独检查的是插件是否依赖未实现的钩子、旧的输出选项，或在 JavaScript 与 Rust 运行时之间传递了特殊对象。React 项目还要留意 @vitejs/plugin-react 的 Oxc 转换路径；需要 React Compiler 或 Babel 插件时，应按官方说明显式接入对应方案。

切包配置更不能只看“构建成功”。manualChunks 仍有兼容支持，但函数形式已标记弃用；Rolldown 提供更细的 advancedChunks。旧规则可以先保留并观察产物，再把明确的 vendor 分组迁移到新配置。检查点不是配置文件里出现了新名字，而是关键入口的 chunk 数量、首屏资源和动态导入关系符合预期。

最后保留一次可回退的验证：执行 npm run build，确认退出码为 0；查看是否出现未知输出选项警告；对比主入口和动态导入产物；如果只在某个插件启用后失败，就用最小配置复现。遇到原生插件问题时，experimental.enableNativePlugin 可以按官方迁移说明临时降级到 'resolver' 或 false，但这属于定位手段，不应永久掩盖配置问题。

常见问题

Vite 8 是否还需要安装 esbuild？

Vite 本身不再直接依赖 esbuild，但调用 transformWithEsbuild 的插件可能仍需要把 esbuild 声明为开发依赖。能迁移到 transformWithOxc 时，优先按插件文档调整。

升级后必须把 rollupOptions 改成 rolldownOptions 吗？

不必一次性全部改。兼容层会处理许多旧配置，但新项目和持续维护的配置应逐步迁移，并对切包、插件钩子和输出选项做回归检查。

为什么构建成功还要检查 chunk？

构建成功只说明配置和插件完成了这次打包，不代表切包结果符合业务目标。首屏资源、动态导入和缓存边界仍可能因旧的 manualChunks 规则变化。

官方核对入口：Vite 8 发布说明 与 Vite 8 迁移指南。版本或配置持续变化时，以这两处的一手说明为准。