Rolldown 评测：Rust 重写的 Rollup，能否成为 Vite 的下一代打包内核

它解决什么问题：Rollup 的 API，esbuild 的速度

Rolldown 要解决的是一个明确的痛点：Rollup 功能强大、插件生态成熟，但它是纯 JavaScript 实现，打包大型项目时速度跟不上。esbuild 用 Go 写，速度快，但 API 和插件机制与 Rollup 不兼容，迁移成本高。Rolldown 用 Rust 重写，同时承诺提供 Rollup 兼容的 API 和插件接口，让现有 Rollup 用户几乎不修改代码就能获得接近 esbuild 的性能。它的目标用户很清晰：使用 Vite 或 Rollup 的工程团队，尤其是那些构建规模已经让 Node.js 打包器明显吃力的项目。Rolldown 的 README 直接写明它是 VoidZero 的项目，而 VoidZero 的公告提到要打造下一代 JavaScript 工具链。所以这不是一个孤立工具，而是整套工具链战略的一部分。

核心机制：Rust 内核加 napi-rs 桥接

Rolldown 的架构可以从仓库结构看出来。核心打包逻辑用 Rust 编写，通过 napi-rs 生成 Node.js 原生插件。napi-rs 是一个用 Rust 写 Node 插件的框架，它让 Rolldown 能以原生模块的形式在 Node 中加载。底层解析器、解析器和 sourcemap 支持来自 oxc 项目，这是一个用 Rust 写的 JavaScript 工具库。也就是说，Rolldown 不是从零写解析器，而是站在 oxc 的肩膀上。打包流程大致是：输入 JavaScript 或 TypeScript 文件，Rust 内核进行解析、模块解析、依赖图构建、代码转换和打包，最后输出 bundle。插件接口模仿 Rollup 的 hook 机制，但执行在 Rust 侧或通过桥接调用 JavaScript 插件。README 提到它提供 Rollup 兼容的插件接口，但范围更接近 esbuild，这意味着它不是 100% 复刻 Rollup 的每一个细节，而是聚焦于核心功能。

上手方式：npm 安装与基本命令

Rolldown 的安装方式与 Rollup 类似，通过 npm 包 'rolldown' 分发。最新版本是 v1.2.6，发布于 2026 年 8 月 26 日。根据文档站的指引，你可以用 npm install rolldown 安装，然后通过命令行或 JavaScript API 使用。文档没有给出具体命令示例，但可以推测它支持类似 rollup -c 的配置文件方式，以及通过 import { rollup } from 'rolldown' 的编程接口。仓库的 StackBlitz 示例（rolldown-starter-stackblitz）提供了一个在线启动模板，你可以直接 fork 来体验。对于不同平台，它提供了多个绑定包，如 @rolldown/binding-darwin-arm64、@rolldown/binding-linux-x64-gnu、@rolldown/binding-win32-x64-msvc 和 @rolldown/binding-wasm32-wasi。这意味着它通过预编译二进制支持主流平台，同时提供 wasm 版本作为后备。实际使用时，你需要根据你的操作系统选择合适的绑定包，或者让 npm 自动解析。配置方面，Rolldown 大概率支持 Rollup 风格的 input、output、plugins 等配置项，但具体字段需要查阅 rolldown.rs 的文档。

一个真实的局限：插件兼容性与 wasm 性能

Rolldown 最大的局限在于插件生态的兼容性。虽然它声称提供 Rollup 兼容的 API，但 Rollup 插件生态非常庞大，很多插件直接操作 Rollup 内部的 AST 或使用特定 hook，这些在 Rolldown 中可能无法直接运行。README 明确说它“will be more similar to esbuild in scope”，这意味着它可能不会实现 Rollup 的所有高级功能，比如某些代码分割策略或 tree-shaking 的极端场景。另一个局限是 wasm 绑定。对于不支持原生二进制的平台，Rolldown 提供 wasm32-wasi 绑定，但 wasm 运行速度远低于原生代码，这会让性能优势大打折扣。如果团队需要在受限环境中使用 wasm，那么 Rolldown 的“快”就名不副实了。此外，Rolldown 仍处于快速迭代阶段，v1.2.x 系列意味着 API 可能还不稳定，升级版本可能带来 breaking change。对于追求稳定性的生产项目，这是一个需要警惕的风险。

替代方案：Rollup 与 esbuild 的真实差异

Rolldown 的直接替代品是 Rollup 和 esbuild。Rollup 是纯 JavaScript 打包器，API 和插件生态是 Rolldown 的参照系，但性能不如 Rust 实现。esbuild 用 Go 写，速度极快，但它的插件接口是自定义的，与 Rollup 不兼容，而且它更专注于打包速度，功能范围比 Rollup 窄。Rolldown 的定位是介于两者之间：用 Rust 获得接近 esbuild 的速度，同时保持 Rollup 的 API 兼容性。另一个相关项目是 Vite，但 Vite 本身依赖打包器，目前使用 esbuild 做依赖预构建，用 Rollup 做生产构建。如果 Rolldown 成熟，Vite 可能会切换到 Rolldown，这正是 README 中提到的目标。所以如果你已经在用 Vite，Rolldown 的替代意义是未来的 Vite 版本可能内置它，而不是你现在直接替换。如果你只是需要快速打包，不想迁移插件，esbuild 依然是更简单的选择。

维护与升级成本：MIT 许可与第三方代码

Rolldown 采用 MIT 许可证，这是一个宽松的许可，允许商业使用和修改。但需要注意，它包含从 Rollup 和 esbuild 派生的代码，这些代码也遵循 MIT 许可，但相关许可证文本列在 THIRD-PARTY-LICENSE 文件中。这意味着如果你要分发基于 Rolldown 的修改版本，你需要保留这些许可声明。维护成本方面，Rolldown 的发布频率较高，从 v1.2.4 到 v1.2.6 每隔一周左右发布一个版本，说明项目非常活跃。但这意味着升级节奏快，你需要定期跟进更新。由于它是 Rust 项目，如果你需要修改内核，你需要 Rust 工具链和 napi-rs 的知识，这比纯 JavaScript 项目的学习曲线陡峭。如果你的团队没有 Rust 经验，那么你只能依赖官方发布的二进制包，无法自行编译或修复底层问题。

结论：谁该用，谁不该用

Rolldown 适合那些已经在 Rollup 生态中投入大量插件资产、但被构建速度困扰的团队。如果你们是 Vite 用户，那么 Rolldown 是未来 Vite 的官方方向，值得提前熟悉。不适合那些只需要简单打包、不想处理原生二进制依赖的项目，或者对 wasm 性能有要求的场景。采用前，先验证你的 Rollup 插件在 Rolldown 下是否工作，尤其是那些依赖 rollup 内部 API 的插件。同时，检查你的目标平台是否有对应的绑定包，比如 Windows 的 msvc 版本。最后，锁定一个具体版本，比如 v1.2.6，并在 CI 中测试，因为项目迭代快，API 可能变动。Rolldown 的最终价值取决于它能否在保持 Rollup 兼容性的同时，真正兑现 Rust 的性能承诺，而这一点只能通过实际项目验证。

编辑结论

Rolldown 适合那些已经深度使用 Rollup 插件生态、但受限于 Node.js 打包性能的团队，尤其是 Vite 用户，因为它在 API 层面几乎可以无缝替换 Rollup，同时获得 Rust 的速度。不适合对打包体积或启动时间极度敏感、且依赖 esbuild 专有特性的项目，因为 Rolldown 明确表示范围更接近 esbuild，但插件兼容性仅针对 Rollup。采用前应先验证三件事：你的 Rollup 插件是否全部能在 Rolldown 下运行，尤其是那些直接操作 AST 或使用 rollup 内部 hook 的插件；Rolldown 的 wasm 绑定是否满足你需要的目标平台；以及当前版本（如 v1.2.6）的已知 issue 是否影响你的构建流程。Rolldown 尚在快速迭代中，API 可能变动，生产环境采用前应锁定版本并阅读 rolldown.rs 的迁移指南。最终判断：如果你的项目是 Vite 或 Rollup 的长期用户，Rolldown 值得作为实验性替代，但不要在生产环境盲目切换，先跑通一个最小复现。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes