Rspack 相比 Webpack 性能到底强在哪？
Rspack 是字节跳动基于 Rust 开发的下一代构建工具，目标很明确：在保持和 Webpack 高度兼容的前提下，把构建速度提上去。
为什么 Rspack 比 Webpack 快？
核心原因只有一个——Rspack 用 Rust 写的，Webpack 用 JavaScript 写的。这不是"稍微快一点"的差距，而是系统级语言和脚本语言之间本质的性能鸿沟。
具体来说，差距体现在以下几个层面。
Rust 原生性能
Rust 编译后的机器码直接跑在 CPU 上，不存在 V8 引擎的解释和 JIT 编译开销。拿最基础的模块解析来说，Webpack 需要通过 Node.js 的 fs 模块做文件 I/O，每一次调用都要经过 JavaScript 运行时的调度；Rspack 直接用 Rust 的文件系统 API，路径解析、文件读取都少了中间层，单这一项就能拉开几倍的差距。
另外 Rust 的零成本抽象不是说说而已——你用泛型、trait 这些高级特性写出来的代码，编译之后和手写底层代码性能几乎一样。所以 Rspack 既能保持代码可维护性，又不牺牲运行效率。
多核并行构建
这是拉开差距最大的地方。Webpack 的核心构建流程基本是单线程的，虽然 loader 可以开 worker，但模块依赖图（Dependency Graph）的构建和 chunk 生成是串行的。项目一大，CPU 使用率看着很低，构建时间却死活降不下来。
Rspack 从架构层面就把并行设计进去了：
- 模块解析阶段，多线程同时处理不同入口的依赖关系
- Loader 执行阶段，独立模块的转换可以并行跑
- 代码生成阶段，不同 chunk 的产物可以同时输出
字节跳动内部的大型项目（上万模块）实测数据：构建时间从 3 分钟降到 10 秒左右，提升约 18 倍。这个数字不是理论值，是真实业务项目跑出来的。
增量构建和持久化缓存
Webpack 5 引入了持久化缓存，这算是补上了重要的一课。但 Rspack 在增量构建上做得更激进：
- 模块级别的变更检测，只重编真正改过的文件及其依赖链
- 缓存粒度更细，不只是缓存到模块级别，部分中间产物也做了缓存
- 持久化缓存开箱即用，不需要像 Webpack 那样手动配置 cache.type
实际开发中，改一个组件后 HMR 的响应时间基本在 100ms 以内，Webpack 在大项目里经常要 1-3 秒。
模块解析优化
Rspack 对模块解析做了几件事：
- 批量文件系统调用——把分散的 stat/readfile 调用合并成批量操作，减少系统调用的次数
- 增强路径解析缓存——同一个 resolve 请求不重复计算，缓存命中率极高
- 更紧凑的依赖图数据结构——用 Rust 的 Vec/HashMap 替代 JavaScript 的对象，内存占用和访问速度都更优
这些优化单个看提升不大，但叠加在一起效果显著。大型项目里光模块解析阶段就能快 5-8 倍。
代码分割和 Tree Shaking
Rspack 在产物优化上也做了不少工作：
- Tree Shaking 的实现更精确，能识别 Webpack 可能误判的 side effect
- 代码分割策略更灵活，支持更细粒度的 chunk 划分
- 产物体积通常比 Webpack 小 5-15%
这意味着不仅构建快，产出的代码也更精简。
内存管理
Rust 没有垃圾回收（GC），内存分配和释放都是确定性的。Webpack 跑在 Node.js 上，项目一大，GC 暂停就成了问题——构建到一半停下来做垃圾回收，几十秒就没了。
Rspack 的内存管理有几个明显优势：
- 无 GC 暂停，构建过程不会出现突然卡顿
- 内存占用比 Webpack 低 30-50%，同样的机器能构建更大的项目
- 构建完成后内存立刻释放，不会像 Node.js 那样存在内存驻留
插件兼容和迁移成本
说性能不说迁移成本就是耍流氓。Rspack 的核心设计目标之一就是兼容 Webpack 生态：
- webpack 配置文件可以直接用，改个 import 路径的事
- 常用 loader（babel-loader、css-loader、style-loader 等）原生支持
- 常用插件覆盖率达到 90% 以上
- 字节跳动内部数百个项目已完成迁移，平均迁移时间 1-2 天
Rspack 1.0 正式版发布后，社区反馈的兼容性问题已经很少了。大多数 Webpack 项目改几行配置就能跑起来，构建速度直接提升 5-10 倍。
实际性能数据对比
拿一个典型的中大型前端项目（500+ 模块）做对比：
| 指标 | Webpack 5 | Rspack 1.0 | 提升倍数 |
|---|---|---|---|
| 冷启动 | 45s | 3s | 15x |
| 增量构建 | 2.5s | 0.15s | 17x |
| 生产构建 | 120s | 8s | 15x |
| 内存占用 | 1.8GB | 0.9GB | -50% |
数据来源是 Rspack 官方基准测试和社区实测，具体数字因项目而异，但量级基本在这个范围。
什么时候该考虑迁移？
如果你的项目满足以下条件，迁移到 Rspack 基本是稳赚不赔的：
- 项目用 Webpack 5，构建时间超过 30 秒
- 团队不想大改构建配置，只想提升速度
- 项目主要用社区主流 loader 和插件
如果项目重度依赖 Webpack 的内部 API 或自定义插件，建议先跑一遍 Rspack 的兼容性检查再决定。