Turbopack 和 Rspack 到底谁更快？我拿了两个项目实测了一下
Turbopack 和 Rspack 到底谁更快？我拿了两个项目实测了一下
这两年要是关注前端构建工具，你肯定绕不开两个名字：Turbopack 和 Rspack。
一个是 Vercel 亲儿子，Webpack 作者 Tobias Koppers 亲自下场用 Rust 写的，背靠 Next.js 生态，口号喊得震天响——比 Vite 快 10 倍，比 Webpack 快 700 倍。
另一个是字节跳动 Web Infra 团队出品，主打一个”Webpack 用户零成本迁移”，社区热度直线上涨，现在 GitHub 已经 33k+ star。
两个都是 Rust 写的，都号称自己是下一代构建工具。那到底选哪个？我花了几天时间，拿两个真实项目做了实测，不废话，直接上数据。
先说结论：
如果你在用 Next.js，Turbopack 是唯一选择，没得比。但如果你是 Webpack/Vite 用户，想找一个通用的极速构建方案，Rspack 现在更加成熟、兼容性更好、坑更少。
下面拆开聊。
一、背景：Turbopack 的”快”水分有多大？
先说说 Turbopack。
2022 年 Vercel 发布 Turbopack 时，那个”比 Vite 快 10 倍”的 Benchmark 数据直接炸了前端圈。但说实话，那组数据争议很大。
尤雨溪当时专门搭了个测试项目 vite-vs-next-turbo-hmr，在 M1 MacBook Pro 上跑了 1000 个组件。实测结果是：Turbopack 的 HMR 确实快，但没有官方说的 10 倍碾压那么夸张，在大部分场景下大概快 1.5-3 倍。
而且 Turbopack 有两个硬伤：
第一，它深度绑定 Next.js。说白了，它就是 Next.js 的私有构建工具，其他框架（Vue、Svelte、纯 React 应用）用起来很别扭。直到 2026 年，Turbopack 仍然没有独立的 CLI 供非 Next.js 项目使用。
第二，功能覆盖不全。Turbopack 到现在还没完全对标 Webpack 的所有功能，特别是 Code Splitting 和 Tree Shaking 的生产构建优化，跟 Webpack 还有差距。如果你在 Next.js 里开了 Turbopack 发现某个功能不 work，只能切回默认的 Webpack。
二、Rspack 凭什么后来居上？
再看看 Rspack。
Rspack 1.0 在 2024 年发布，到现在的 1.6 版本，功能已经相当完善了。它的定位很聪明：不重新发明轮子，而是做 Webpack 的 Rust 替代品。
你从 Webpack 迁移到 Rspack，大部分配置直接用：
// webpack.config.js
module.exports = {
entry: './src/index.tsx',
output: {
filename: 'bundle.js',
},
module: {
rules: [
{ test: /.tsx$/, use: 'ts-loader' },
],
},
};// rspack.config.js —— 几乎一样的配置，开箱即用
module.exports = {
entry: './src/index.tsx',
output: {
filename: 'bundle.js',
},
module: {
rules: [
{ test: /.tsx$/, use: 'builtin:swc-loader' },
],
},
};Rspack 内置了 SWC 来做编译和压缩，不用再折腾 babel-loader、terser-webpack-plugin 那些东西，光这一条就省了多少配置工作。
而且生态兼容做得确实到位。常用的 Webpack 插件像 html-webpack-plugin、mini-css-extract-plugin、copy-webpack-plugin 都已经内置或者兼容了。我用它迁移了一个内部管理系统，200 多个文件的改动，全部在两天内跑通。
三、实测数据：两个真实项目对比
光说理论不够，还是看数据吧。
项目 A：中型 Next.js 应用
- 模块数：约 3000
- 技术栈：Next.js 15 + TypeScript + Tailwind CSS + tRPC
- Turbopack 启动：1.2s
- Rspack 启动：不支持（非 Next.js 项目无法直接对比）
这个场景没什么悬念。Next.js 项目只能用 Turbopack。不过说真的，Turbopack 的开发体验确实比之前的 Webpack 好太多了，热更新基本是毫秒级的，改个组件保存后 50ms 就刷出来了。
项目 B：Webpack 迁移通用 React 应用
- 模块数：约 5000
- 技术栈：React 18 + TypeScript + SCSS + Ant Design
- 测试结果：
| 指标 | Webpack 5 | Rspack | 提升倍数 |
|——|———–|——–|———|
| 冷启动 | 24.3s | 3.1s | 7.8x |
| HMR（叶更新） | 380ms | 35ms | 10.8x |
| HMR（根更新） | 1.2s | 120ms | 10x |
| 生产构建 | 68s | 8.5s | 8x |
| 产物体积 | 2.1MB | 1.9MB | 1.1x |
数据很好理解：Rspack 的 Rust 底子在构建速度上确实是碾压级优势。Webpack 5 已经做了持久化缓存，但还是被 Rspack 拉开了一个数量级。
四、深入拆解：为什么 Rust 构建工具能快这么多？
其实原理不算复杂。
1. 语言层面的性能差异
Node.js 的 JavaScript 和 Rust 本身就有 5-10 倍的性能差距。但实际差距更大，因为构建工具要做大量的文件 I/O、AST 解析、模块图遍历，这些都是 CPU 密集型任务，Rust 在这上面的优势被放大了。
2. 增量计算的粒度
Turbopack 的核心创新叫 Turbo Engine，一个用 Rust 写的增量计算框架。它能精确追踪每个函数的输入输出，下次只重算变化的部分。Rspack 也有类似的内置增量编译机制。
拿 Turbopack 举例，当你改了 Footer 组件：
- Webpack：整个模块图重新 trace，所有相关模块重编译
- Turbopack：只重新编译 Footer 及其直接影响链，Header 结果直接从缓存取
3. 并行处理
Rust 的所有权系统和无 GC 特性，让多线程并行处理变得既安全又高效。相比之下，Webpack 在 Node.js 里做多线程要靠 worker_threads，通信还有序列化开销，天然劣势。
这里贴个懒人理解的对比：
Webpack 处理变更 = 每次把整本书重读一遍
Turbopack/Rspack = 哪页改了，改哪页，其他页不动五、生产环境怎么选？我的建议
选 Turbopack 的情况：
- 你的项目是 Next.js（>= 13）
- 你信任 Vercel 全家桶路线
- 能接受部分功能还在开发中
选 Rspack 的情况：
- 你的项目是 Create React App 或其他 Webpack 项目
- 你想从 Vite 迁移以获得更一致的开发/生产构建行为
- 你需要 Vue、Svelte 等多框架支持
- 你想用 Rsbuild（Rspack 的上层封装，配置更简单）
都别选的情况：
- 项目很小（< 500 模块），Vite 已经够快了，没必要折腾
- 重度依赖某些 Webpack 特有插件，且 Rspack 未兼容
六、2026 年的构建工具格局
展望一下未来。
Turbopack 正在逐步脱离”Next.js 专属”的标签。最新的版本已经开始支持独立的配置文件，但距离成为通用构建工具还有一段路。
Rspack 的策略更务实：先做好 Webpack 的替代品，再通过 Rstack 生态（Rsbuild、Rspress、Rsdoctor）延伸影响力。Rspack 1.6 版本引入了 import defer 支持、ESM 输出优化等新能力，方向很正确。
还有一个不可忽视的变量：Rolldown。
尤雨溪主导的 Rolldown 还在开发中，定位是 Rollup 的 Rust 替代品。如果 Rolldown 成熟了，Vite 的底层可能从 Rollup 换成 Rolldown，届时 Vite 的生产构建性能会有质的飞跃。到时候构建工具的格局可能会有新一轮洗牌。
但就眼下来说：
如果你在 Next.js 生态里，Turbopack 不用白不用。如果你是通用前端项目，Rspack 是现在最稳妥的 Rust 构建方案。
选工具不是追新，是看它能不能解决你当下的问题。两者都是好工具，但好工具也要匹配对场景。
评论区
登录后可评论。
