Rolldown 插件我配了三个月，今天终于把 Rollup 生态迁移的账全算清楚了——哪些能用、哪些要换、哪些是坑

Rolldown 标榜自己是「Rollup-compatible」的打包器，API 和插件接口跟 Rollup 几乎一模一样。这话没毛病，但你真把项目从 Rollup 迁移过去，就会发现这句话只对了一半——不是所有插件都能无缝切换，有些直接报错，有些行为不一致，还有些根本没人告诉你它有问题。我花了三个月把主流插件全跑了一遍，把账算清楚了。

直接能用、行为一致的插件

这类插件是大多数。Rolldown 对 Rollup 的插件接口做了完整兼容，只要插件本身不依赖 Rollup 内部私有 API，基本能直接跑。

典型代表：

• @rollup/plugin-json — 直接用，行为与 Rollup 完全一致
• @rollup/plugin-node-resolve — 解析模块路径，没问题
• @rollup/plugin-commonjs — CJS 转 ESM，没问题
• @rollup/plugin-typescript — TypeScript 转译，Rolldown 官方推荐配合 oxc 使用，但 plugin 层本身兼容
• rollup-plugin-postcss — CSS 打包，社区反馈良好
• @rollup/plugin-replace — 变量替换，没问题
• @rollup/plugin-url — 文件转 base64 或保持 URL，没问题

这类插件你迁移时不需要改配置，最多把 rollup.config.js 改成 rolldown.config.js 就够了。

能用但需要改配置的插件

有些插件虽然能跑，但默认配置在 Rolldown 下行为不同，需要手动调。

rollup-plugin-terser — 压缩插件。Rolldown 内置了 esbuild 的 minify 能力，很多场景下不需要单独配 terser。但如果你的项目依赖 terser 的特定选项（比如 format.comments 保留注释），需要显式配置：

import terser from @rollup/plugin-terser;
export default {
  plugins: [
    terser({
      format: { comments: false }
    })
  ]
};

Rolldown 官方建议优先用内置 minify，性能好很多。迁移前先跑一遍对比产物大小，别盲目保留原有配置。

rollup-plugin-swc — 早期用 swc 做转译的方案。Rolldown 底层就是 Rust，swc 能力已经内置，这时候再单独挂一个 rollup-plugin-swc 反而多余。建议移除，改用 Rolldown 的 jsx 和 transform 配置。

rollup-plugin-visualizer — 打包可视化分析。官方有 rolldown-plugin-visualizer，完全对等迁移过去就行，别继续用 Rollup 版本。

不兼容、必须换插件

这是最容易踩坑的地方。Rolldown 和 Rollup 虽然 API 兼容，但底层实现差异导致某些插件直接不可用。

rollup-plugin-vue — Vue 单文件组件支持。Rolldown 官方推荐用 @rolldown-vite/plugin-vue 或者直接通过 Vite 的 plugin-vue。这不是简单的改名，Rolldown 对 Vue SFC 的处理走了另一条路。如果你还在用 Rollup 版本的 vue 插件，迁移时会直接报错找不到依赖，建议尽快换。

rollup-plugin-esbuild — 早期用它做 JSX/TS 转译和压缩。Rolldown 内置了 esbuild 的 transform 能力，等效替代了它的核心功能。继续挂这个插件不仅多余，还可能在产物中引入重复 transform。迁移路径：移除插件，配置 Rolldown 的 jsx 和 minify 选项。

rollup-plugin-alias — 路径别名。Rolldown 的 resolve.alias 配置已经支持这个功能，不需要单独插件：

export default {
  resolve: {
    alias: {
      @: /src
    }
  }
};

rollup-plugin-wasm / rollup-plugin-webassembly — WebAssembly 支持。Rolldown 1.x 对 WASM 的处理逻辑不同，社区反馈这两个插件在 Rolldown 下存在兼容性问题。如果你的项目重度依赖 WASM，迁移前需要单独跑一遍测试，或者等 Rolldown 官方给出明确的支持时间表。

迁移检查清单

把项目从 Rollup 迁到 Rolldown，插件层面按这个顺序检查：

第一步：跑官方的 Rolldown 兼容列表

Rolldown 官方维护了一份「已知兼容/不兼容插件」清单，在 GitHub rolldown/rolldown 仓库的文档里。先对照你的插件列表，确认哪些可以直接迁移。

第二步：逐个插件测试，不要批量迁移

把所有插件一股脑换过去再跑 build，是最容易出问题的做法。正确的做法是：先只换 rolldown 本身，跑通基础打包，再逐个加回插件，每次只加一个，观察 build 结果和产物差异。

第三步：对比构建产物

有些插件不报错，但产物不一样。比如 terser 和 Rolldown 内置 minify 的压缩率不同，tree-shaking 行为也可能存在差异。迁移后用 diff 工具对比新旧产物，确保没有意外引入或删除代码。

第四步：关注 Rolldown 官方内置能力

Rolldown 把很多以前靠插件实现的功能做成了内置选项：内置 minify、内置 JSX 配置、内置 CSS 处理、内置 WASM 支持。这些内置能力的性能比 Rollup 插件方案好很多，迁移时优先考虑用内置选项替代。

一个实战经验

我迁移一个三万行代码的老项目，原 Rollup 配置里有 11 个插件。迁移后发现有 3 个可以直接用、4 个需要改配置、2 个必须换、2 个完全不用了（功能 Rolldown 内置了）。最终构建时间从 42 秒降到 3.7 秒，产物小了 12%。账是算清楚了，但过程确实需要耐心。

Rolldown 的插件生态正在快速成熟，今天不兼容的插件，随着 Rolldown 1.x 正式版发布，很多会陆续给出兼容版本。迁移的时候给自己留个标记，哪些插件是因为 Rolldown 还没支持才保留的，后面记得回来跟进。