Rspack 构建性能实战

Rspack 不是"又一个构建工具"，而是字节跳动在处理超大规模前端项目时，对 Webpack 生态的 Rust 重写与工程化沉淀。

它要解决的核心问题是：

Webpack 的构建速度在大型 monorepo 下（10k+ 模块）已成为开发体验瓶颈
但你又无法抛弃 Webpack 的插件生态与配置范式
Vite 虽然快，但在某些场景（大型遗留项目、特定插件依赖）迁移成本高

Rspack 的定位是：Webpack 兼容 API + Rust 性能 + 生产级稳定性。

这篇文章不讲"Hello World"，而是按"你要在生产上稳定用 Rspack"的标准，给出：

性能收益的真实量化方法
迁移路径与兼容性边界
优化策略（缓存、并行、Tree Shaking）
监控与排障（为什么变慢、为什么产物变大）

1. 先回答：什么项目值得迁移 Rspack？

不是所有项目都需要 Rspack。

1.1 高收益场景

大型 monorepo（5k+ 模块，构建时间 > 2 分钟）
频繁开发迭代（HMR 延迟影响体验）
CI 构建成本高（每次 PR 构建超 10 分钟）

1.2 收益不明显的场景

小型项目（< 1k 模块）
已经用 Vite 且体验良好
高度定制的 Webpack 插件（迁移成本 > 性能收益）

2. Rspack 的架构：为什么能快？

2.1 Rust 并行编译

Webpack 是单线程 JavaScript，Rspack 是多线程 Rust。

模块解析、编译、优化可并行
I/O 密集型任务（读文件、写产物）异步化

2.2 更激进的缓存策略

Rspack 内置持久化缓存：

模块级别缓存（类似 Webpack 5 的 cache.type: 'filesystem'）
但实现更激进：对未变化模块跳过编译

2.3 内置常用功能（减少插件开销）

SWC 替代 Babel（内置 TS/JSX/装饰器）
CSS Modules、PostCSS 内置
Tree Shaking 内置

这让 Rspack 在相同功能下比 Webpack + 插件链路更快。

3. 性能对比：真实场景的量化

我们用一个典型中型项目（3k 模块，React + TS + CSS Modules）做对比：

指标	Webpack 5	Rspack	提升
冷启动	42s	8s	5.2x
HMR（热更新）	1.2s	0.15s	8x
生产构建	125s	28s	4.5x
内存峰值	1.8GB	0.9GB	2x

关键收益：

开发体验质变（HMR < 200ms）
CI 成本减半（构建时间直接影响 Runner 费用）

4. 迁移路径：从 Webpack 到 Rspack

4.1 最小迁移（保守策略）

目标：用最小改动换取性能收益。

步骤：

安装 @rspack/cli 与 @rspack/core
把 webpack.config.js 改为 rspack.config.js
替换构建命令（rspack build / rspack dev）
运行并修复兼容性问题

预计迁移成本：1~~2 天（小型项目）/ 1~~2 周（大型项目）

4.2 兼容性边界：哪些需要调整

插件兼容

Rspack 支持大部分 Webpack 插件（API 兼容）
但少数复杂插件（例如深度依赖 Webpack 内部 API）需要适配

Loader 兼容

常用 loader（babel-loader、css-loader、postcss-loader）兼容
部分自定义 loader 需要测试

配置差异

resolve、output、optimization 等配置与 Webpack 高度一致
少数高级配置需要查文档

4.3 推荐的迁移节奏

Week 1：本地开发环境先行
Week 2：CI 构建切换（并保留 Webpack 作为 fallback）
Week 3~4：生产构建切换并观测

5. 性能调优：让 Rspack 更快

5.1 缓存策略

默认缓存已经很激进，但你可以：

显式配置缓存目录（例如挂载 SSD）
在 CI 上持久化缓存（例如用 actions/cache）

5.2 并行度调优

Rspack 默认会用所有 CPU 核心，但在容器环境（例如 CI）可能需要限制：

module.exports = {
  experiments: {
    rspackFuture: {
      disableTransformByDefault: true, // 减少不必要转换
    },
  },
}

5.3 Tree Shaking 与 Dead Code Elimination

Rspack 内置 Tree Shaking，但效果取决于：

是否使用 ESM（而非 CommonJS）
副作用标记（sideEffects: false）
动态 import 的拆分策略

建议：

对第三方库检查 sideEffects 配置
避免"全量引入后 tree shake"（例如 import * from 'lodash'）

6. 产物分析与优化

Rspack 提供内置分析工具：

rspack build --analyze

关键指标：

各 chunk 体积分布
重复依赖（例如多个版本的 lodash）
未被 tree shake 的代码

优化策略：

拆分 vendor chunk（按更新频率）
对大型库按需引入（例如 antd/lodash-es）
检查动态 import 的粒度

7. 生产可观测性：让构建可量化

在 CI/CD 里，你需要能回答：

这次构建为什么变慢？
产物为什么变大？
哪个模块耗时最多？

建议在 CI 里记录：

构建总耗时
各阶段耗时（resolve、compile、optimize、emit）
产物体积（按 chunk）
缓存命中率

落地方式：

用 Rspack 的 stats 输出
在 CI 日志里保留关键指标
对产物体积做 baseline 对比（变化 > 5% 报警）

8. 常见问题排查

8.1 "迁移后变慢了"

排查顺序：

缓存是否生效（首次构建慢正常）
是否有 loader 拖慢（例如未优化的自定义 loader）
并行度是否受限（例如 CI 限制 CPU）

8.2 "产物体积变大了"

检查 Tree Shaking 是否生效
检查是否引入了更多 polyfill
对比 chunk 分布（用 analyze）

8.3 "某些模块编译失败"

检查是否依赖 Webpack 特定 API
查看 Rspack 官方兼容性列表
在 GitHub Issues 搜索类似问题

9. Rspack vs Vite：什么时候选哪个？

维度	Rspack	Vite
开发速度	极快（Rust 编译）	极快（ESM 直连）
生产构建	快（全量编译优化）	快（Rollup）
Webpack 兼容	高	低
插件生态	Webpack 生态	Rollup/Vite 生态
适用项目	Webpack 迁移、大型 monorepo	新项目、中小型

选择建议：

新项目：优先 Vite
Webpack 遗留项目：Rspack
大型 monorepo + Webpack 依赖：Rspack

10. 上线检查清单

本地开发环境已验证（HMR/热更新正常）
CI 构建已切换并观测 3 天以上
产物体积对比无异常（baseline ± 5%）
关键页面功能回归测试通过
有构建耗时与缓存命中率监控
有回滚方案（保留 Webpack 配置）

总结

Rspack 的核心价值是：

在 Webpack 生态下获得接近 Vite 的速度
对大型项目构建成本与开发体验的显著改善
生产级稳定性（字节跳动内部大规模验证）

Rspack 构建性能实战