Rolldown：用 Rust 编写、兼容 Rollup 的打包器

Rolldown 的动机

• 该项目将自己定位为“用 Rust 实现、与 Rollup 兼容”，旨在修复两个被认为存在的问题：esbuild 的代码分割能力较弱，以及 Rollup 的构建速度较慢。
• 评论者指出，它实际上是“下一代 Rollup”，同时也是对基于 Rust 的 webpack 替代方案 rspack 的回应。
• 有人认为，它是 JS 工具链中更广泛的 Rust 浪潮的一部分（oxc、SWC、LightningCSS、Deno 等）。

为什么不直接改进 esbuild 或 Rollup？

• Esbuild：据说非常难以扩展；多项功能（打包、treeshaking、转换）被紧密耦合在少数几个 AST 遍历中，使得除维护者之外的人很难进行大规模重构。
• 它的代码分割受 ES 模块语义以及项目优先级限制，项目更偏向正确性，而不是冒险采用“更快但可能不正确”的模式。
• Rollup：受限于它是基于 JS 的，且多核利用率较差；将 JS 代码与原生转换（SWC、esbuild）混用，会因重复的解析/序列化步骤以及 JS/原生边界跨越而带来额外开销。

为什么是 Rust？

• 支持 Rust 的观点：性能强、多线程编程容易且有编译期安全保证、对解析器很友好（模式匹配、代数数据类型），并且拥有一个由 Cargo 和 crates.io 构成的统一生态。
• 批评者认为，任何 AOT 编译语言（Go、C#、C++）都可以胜任；对于典型的工具链工作负载而言，Rust 的借用检查器可能只是徒增复杂度，甚至导致对 .clone() 的滥用。
• 讨论中大量比较了 JS、Go、C++、C# 和 Rust 在性能、安全性、迭代速度以及工具链方面的差异（Cargo vs CMake、缺乏 C++ 包管理器等）。

采用、Vite 集成与生态担忧

• Rolldown 与 Vite 生态紧密相关；有人认为它将成为 Vite 的长期替代方案，Vite 5.1 材料中也提到了早期实验。
• 有些人担心 Rust 核心会缩小贡献者范围，因为大多数 JS/TS 开发者很难直接为它修补问题。
• 也有人在问，其输出质量（可读性、非“垃圾”式的 bundle）是否能与 Rollup 持平，以及它是否会通过直接转换 AST 来避免 Rollup 那种 MagicString 风格的字符串拼接式操作。

用例与开放问题

• Chunking 被认为对加载大型、按路由分隔的依赖和动态导入很重要，不过也有人质疑很多应用是否真的需要它。
• 目前还不清楚 Rolldown 何时能在 Vite 中达到生产可用，以及它是否会完全统一开发和构建行为（“dev mode as build-plus”）。