从 Webpack 迁移到 Rspack，别再只盯着构建速度看了

如果你的项目还在 Webpack 5 上慢悠悠地跑 dev server，同时隔壁团队已经在用 Rspack 把冷启动从 40 秒压到了 5 秒，这篇文章就是给你看的。

过去一年，Rspack 在字节、Shopee、Vercel 的落地案例里，已经不只是一次“换打包器”的升级，而是一次工程化切面：配置兼容性、插件生态、HMR 行为、CI 缓存，这些才是真正影响迁移成本的地方。

1. 先判断值不值得迁

不是所有项目都适合立刻迁。优先看这几个信号：

• 本地冷启动 > 20 秒，且 dev server 重启频繁
• CI 构建 > 8 分钟，且缓存命中率低
• 项目里大量使用 loader/plugin，但 Webpack 5 迁移已经碰壁
• 团队已经在用 Rust 工具链，且愿意接受少量兼容成本

2. 最小成本迁移路径

Rspack 的卖点之一，就是尽量兼容 Webpack 配置。你可以按这个顺序推进：

1. 装 Rspack 和 @rspack/cli
2. 把 webpack.config.js 改名为 rspack.config.js
3. 把 require(‘webpack’) 改成 require(‘@rspack/core’)
4. 先跑 build，不追求 dev server 立刻完美
5. 把 HMR 行为、alias、externals 逐项对齐

这里最大的坑不是语法，而是某些 loader 和 plugin 还没提供 Rspack 适配层。

3. 最容易踩坑的 3 个点

• Sass/Less loader：优先用 Rspack 内置的 css-loader 配置，减少外部 loader 依赖
• HtmlWebpackPlugin：Rspack 的兼容度已经很高，但仍建议先跑 offline 模式验证
• CI 缓存：Rspack 的持久化缓存目录和 Webpack 不同，CI 配置要一起改

4. 怎么衡量迁移是否成功

不要只看“快了多少”。建议同时记录：

• 本地冷启动时间
• HMR 生效时间
• CI build 耗时
• 构建结果差异：hash、chunk 数量、资源体积

如果前三项有明显下降，而资源体积没有恶化，就算一次成功迁移。

结论

Rspack 已经不是“试试看”的阶段了。对中型以上项目，它值得一次有准备的迁移；对小型项目，先别急着动，等你的构建成本真的成为瓶颈再说。