以为 Webpack 慢是历史包袱没办法，今天 Rspack 2.0 用三个数字把这件事彻底翻了

写过构建工具的人都以为 Webpack 慢是历史包袱没办法——2026 年这个局面被一份基准测试彻底翻了。10000 个组件的 React 项目，生产构建 1.4 秒，HMR 118 毫秒，这不是新概念机的演示，是 Rspack 2.0 真实项目里的数字。

字节跳动 2023 年开源 Rspack 的时候定位很明确：Rust 写的打包器，API 跟 Webpack 5 兼容，让现有项目可以低迁移成本换过去。三年过去，npm 周下载量从 10 万涨到了 500 万，Next.js、Nuxt、Docusaurus、TanStack Start 这些主流框架都接入了它的生态。2026 年 7 月底 Rspack 2.0 发布，核心主题已经不是「快」，而是「不再是 Webpack 替身，开始走自己的路了」。

迁移成本到底有多低

先说最实在的：你的 webpack.config.js 还能用。

Rspack 2.0 的配置跟 Webpack 5 对齐程度很高，大多数项目改两处就能跑起来。第一，把 webpack 和 webpack-cli 从 package.json 里删掉，装 @rspack/core 和 @rspack/cli；第二，把 package.json 里的 webpack serve 和 webpack build 改成 rspack serve 和 rspack build；第三，配置文件名从 webpack.config.js 改成 rspack.config.js，不改也行，Rspack 默认就认这个文件名。

关键的 loader 替换就一个：所有 babel-loader 换成 builtin:swc-loader。这一个替换带来的提速最明显——SWC 是 Rust 写的，比 Babel 快 20 到 70 倍。大多数常用 loader 像 css-loader、postcss-loader、sass-loader、less-loader、svgr、file-loader、url-loader 都是直接兼容，不用动。HtmlWebpackPlugin 是 drop-in 替换，CopyWebpackPlugin 换成 rspack.CopyRspackPlugin，DefinePlugin 换成 rspack.DefinePlugin，名字空间变了，参数完全一样。

字节跳动内部迁移过数千个模块加数百个 Webpack 插件的真实项目，官方文档的说法是「大多数项目迁移以小时计，不是天」。当然不是 100% 兼容：直接摸到 Webpack 内部 JavaScript 实现的插件会挂；多编译器模式（导出一个配置数组的场景）支持也有限制。但如果你的项目用的是社区主流插件，这两个坑基本碰不上。

基准测试说了一切

拿一个真实 React 项目来测：600 多个组件、300 多条路由、CSS Modules、SVG 引入，测试环境 M3 Pro、32GB 内存、NVMe SSD、Node.js 22.12：

这组数据来自 devtoolsguide.com 的实测，结论很清楚：HMR 速度快了 9 到 12 倍这个量级，不是微优化，是把等待时间从「去看杯咖啡」压缩到了「眨一下眼」。

Rspack 2.0 自身版本之间的进步也值得看。官方用 rspack-react-10k-benchmark 跑，10000 个组件的项目：Rspack 1.0 时生产构建 5.6 秒，1.7 是 3.6 秒，2.0 降到 3.1 秒（无缓存）/ 1.4 秒（有持久化缓存），HMR 118 毫秒。比 1.0 快约 4 倍，比 1.7 快约 2.5 倍，启用持久化缓存后 SWC 压缩结果还能复用，命中缓存时再快 50%，内存占用还降了 20%。

2.0 真正重要的三个变化

第一个是依赖瘦身。@rspack/dev-server 的依赖数从 192 个砍到 1 个，安装体积从 15MB 缩到 1.4MB。装过 @rspack/core 的都知道以前拉一堆传递依赖的痛苦，这个改动把 CI 构建的依赖安装时间也省下来了。

第二个是纯 ESM 化。@rspack/core 去掉 CommonJS 构建，变成纯 ESM 包，Node.js 20.19 以上通过 require() 直接加载 ESM 模块。同时支持 import.meta 和 stage-3 的 import defer，这意味着 Rspack 2.0 不只是跑 Webpack 配置的兼容层，开始往前走了。

第三个是 React Server Components 原生支持。Rspack 2.0 内置了 RSC 支持，不需要额外插件，这是官方路线图里明确写的下一步核心能力。对已经在用 Next.js App Router 或者 Modern.js 这类框架的项目来说，打通 RSC 的构建链路是关键节点。

Rstack 生态现在长什么样

Rspack 只是 Rstack 工具链的核心这一层，往上还有几层。Rsbuild 是应用级构建工具，在 Rspack 基础上封装了零配置预设、语义化配置 API，开发服务器、HMR，常见场景开箱即用，不需要手动调 Rspack 的底层选项。Rslib 专门做类库和 UI 组件开发，支持 dual-format 输出（ESM + CJS）和 API 提取，比 Rsbuild 更贴合 npm 包作者的需求。

文档站用 Rspress（基于 Rsbuild + MDX），构建分析用 Rsdoctor（可视化看构建时间、产物变化、模块引用关系、重复模块），测试用 Rstest（Rspack 生态的测试框架），Lint 用 Rslint（基于 TypeScript-Go，性能比 ESLint 快一个量级）。

这些工具现在基本都有主流框架接入：Next.js 有 next-rspack 插件、Nuxt 有 @nuxt/rspack-builder、Docusaurus 从 3.6 版本开始支持 Rspack、Angular 有 angular-rspack、Storybook 有 storybook-rsbuild。一个团队如果已经用了 Rspack 做主打包器，迁移其他环节到 Rstack 体系的成本很低。

下一步怎么动

如果你现在跑的是 Webpack 5，大型项目（几百个组件以上）建议先拿 CI 环境测 Rspack 2.0 的迁移。最容易出问题的点就两个：自定义插件是否摸到了 Webpack 内部 JS 实现，以及多编译器配置有没有导出数组格式的配置。这两个过了，剩下的就是改三行脚本加装一个包的事。

持久化缓存一定要开。把 node_modules/.cache/rspack 目录在 CI 里持久化，这是构建速度从 9 秒掉到 1.4 秒的关键。如果 CI 每次都是干净环境没缓存命中率，Rspack 的优势会打折扣。

小团队建议直接上 Rsbuild，少踩 Rspack 底层配置的坑。新项目如果技术栈支持，2.0 的 RSC 内置支持是现在唯一一个不需要额外配置就能跑通 App Router 场景的 Rust 打包方案。