Rspack 2.2 评测：用 Rust 重写 webpack 接口，迁移代价与性能收益的权衡

Rspack 要解决什么问题

webpack 是前端打包的事实标准，但它的 JavaScript 实现让大型项目的构建时间越来越长。Rspack 的出发点很直接：用 Rust 重写核心，同时保留 webpack 的 API 和生态，让团队能以较低的迁移成本换取更快的构建。它面向的是那些已经投资了 webpack 生态、但被构建速度困扰的团队。根据 README，Rspack 属于 Rstack 工具链的一部分，这个家族还包括 Rsbuild、Rslib 等，说明它不是一个孤立项目，而是有完整工具链支撑的。对于新项目，你可能更愿意直接用 Rsbuild 这样的上层工具，但 Rspack 本身定位是底层 bundler，适合需要精细控制配置的开发者。

架构与核心机制：Rust 核心加 NAPI 桥接

Rspack 的核心是用 Rust 写的，负责解析、转换、打包这些重活。它通过 NAPI-RS 与 Node.js 通信，这样 JavaScript 侧的配置和插件系统仍然可以运行。README 明确提到，Rspack 的代码解析、转换和压缩由 SWC 提供动力，并发架构则受到 esbuild 的启发。这意味着它并不是从零实现所有功能，而是站在已有 Rust 生态的肩膀上。内置的增量编译机制是 HMR 速度快的关键，但这个机制的具体细节在 README 里没有展开。从仓库结构看，它有一个独立的 rspack_sources crate，是 webpack-sources 的 Rust 移植，说明它连源码操作层面都在向 webpack 对齐。整体架构是：Rust 负责性能敏感部分，JavaScript 负责兼容层，这种混合设计是它能在保持兼容的同时提速的原因。

快速上手：从 webpack 配置迁移的路径

Rspack 的快速开始指南在 rspack.rs/guide/start/quick-start，官方还提供了 StackBlitz 示例可以直接体验。安装方式是通过 npm 包 @rspack/core，这与 webpack 的安装方式类似。配置方面，Rspack 使用 rspack.config.js，其 API 设计模仿 webpack，所以大多数 webpack 配置项可以直接搬过来。例如，entry、output、module.rules 这些核心概念是通用的。不过 README 没有给出具体的配置示例，只提到兼容 webpack 的插件和 loader。实际迁移时，你需要把 webpack.config.js 重命名为 rspack.config.js，然后逐个检查 loader 和 plugin 的兼容性。Rspack 官方提供了 1.x 和 0.x 的文档存档，说明 API 有过多次变化，迁移时要注意版本差异。

性能与生态：宣传的亮点和需要验证的部分

README 强调了 Rust 带来的快速启动和 Lightning HMR，并提供了两个性能对比资源：build-tools-performance 仓库和 ecosystem-benchmark.rspack.rs 网站。这些是官方数据，我没有亲自跑过基准测试，所以不能给出具体数字。但可以确认的是，Rspack 确实内置了 tree shaking 和压缩等生产优化策略，这些是默认开启的。生态方面，它声称兼容 webpack 插件和 loader，这是最大的卖点，但也是最大的风险点。webpack 的插件系统非常复杂，很多插件依赖内部钩子，Rspack 的兼容不可能做到 100%。README 感谢了 webpack 团队和 Module Federation 的创建者，说明它特别重视 Module Federation 的支持，这对于微前端架构是重要的加分项。框架无关性意味着它不绑定 React 或 Vue，这给了团队选择的自由。

已知的局限与误用场景

Rspack 的兼容性是有限度的。虽然它支持 webpack 的插件和 loader，但那些深度依赖 webpack 内部 API 的插件很可能无法工作。例如，一些自定义插件会直接调用 compilation 对象的内部方法，这些在 Rspack 中可能不存在或行为不同。另一个局限是，Rspack 的版本迭代很快，最近一次发布是 v2.2.1，距离 v2.2.0 只有一天，说明修复和功能更新非常频繁。这种速度对追求稳定的生产环境来说是个双刃剑，你可能需要频繁跟进升级。此外，Rspack 的文档分为 2.x、1.x、0.x 三个版本，说明 API 有过破坏性变更，迁移到新版本可能需要调整配置。对于小型项目，构建速度本来就不是瓶颈，引入 Rust 工具链反而增加了复杂度，这时它可能是错误的工具。

与 webpack 的对比：不是替代，而是重构

Rspack 的直接竞争对手是 webpack 本身，但它的策略不是另起炉灶，而是重构。webpack 用 JavaScript 实现，插件生态庞大且成熟；Rspack 用 Rust 重写核心，但保留了 webpack 的 API 设计。这种做法的好处是迁移成本低，坏处是永远无法完全摆脱 webpack 的影子。另一个可对比的工具是 esbuild，它也是 Rust 写的，但 esbuild 的 API 更简洁，不兼容 webpack 插件，因此打包速度更快，但生态支持有限。Rspack 选择了中间路线：性能接近 esbuild，生态兼容 webpack。这个取舍意味着它在某些方面可能不如 esbuild 快，也不如 webpack 兼容，但它试图在两者之间找到平衡。对于已经使用 webpack 的团队，这种渐进式迁移比切换到 esbuild 更平滑。

维护成本与许可证考量

Rspack 采用 MIT 许可证，这对商业项目友好，没有 copyleft 风险。但它依赖的 SWC 项目是 MIT 许可，NAPI-RS 也是 MIT，所以整体许可证风险较低。维护成本方面，Rspack 的发布频率很高，2.x 系列在 2026 年 8 月内就有多个版本，这意味着你需要持续关注更新。官方提供了 Discord 社区和贡献指南，说明项目活跃，但活跃也意味着 API 可能变动。仓库的默认分支是 main，最近一次 push 是 2026-08-27，与最新 release 同一天，说明开发节奏紧密。对于企业用户，建议锁定版本并制定升级计划，避免被快速迭代打乱节奏。此外，Rspack 是 Rstack 的一部分，如果你使用 Rsbuild 或 Rslib，升级时需要考虑这些工具之间的兼容性。

编辑结论

Rspack 适合那些已经深度使用 webpack、且构建速度成为瓶颈的团队，尤其是大型项目或依赖 Module Federation 的微前端架构。它不适合完全脱离 webpack 生态、追求极致简洁的小型项目，也不适合对 webpack 插件兼容性要求极其苛刻、且无法接受任何行为差异的场景。迁移前应先验证：你的自定义 loader 和 plugin 是否在 Rspack 下行为一致，特别是那些依赖 webpack 内部钩子或未公开 API 的插件。检查 rspack.config.js 中每个配置项是否被支持，并利用官方提供的迁移文档和 example 仓库做一次小规模试点。Rspack 的版本迭代速度很快，2.x 的 API 仍在演进，建议锁定版本并关注 release notes。最终判断：如果构建速度是硬需求，Rspack 值得一试；如果生态兼容性优先级更高，可以再等一等。

官方来源

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