webpack 统治前端构建近十年，但随着项目体量膨胀，冷启动与增量构建越来越慢，HMR 热更新等待动辄数秒。社区先后涌现 esbuild、Vite 等以“快”为卖点的方案，但它们要么生态不兼容 webpack 插件，要么仍需自己拼装。Rspack 是字节跳动开源、基于 Rust 的前端构建工具，它最打动人的一点是：在保持 webpack 配置与 loader/plugin 生态兼容的同时，用 Rust 多进程、并行 AST、增量编译把速度拉满。对存量 webpack 项目而言，这是一次几乎零成本的提速升级。
一、为什么前端又需要一个新的打包器
在深入用法前，先回答一个灵魂问题：Rspack 到底解决了什么痛点？前端构建的本质，是把成百上千个模块按照依赖关系拼成一个浏览器能跑的产物，这个过程包含解析、转译、打包、压缩四个阶段。webpack 用单线程 JavaScript 完成这一切，当模块数过万时，每个阶段都会成为瓶颈。
- webpack 慢：单线程 JS 做依赖图与转译，大型仓库冷启动 30s+ 是常态；
- Vite 虽快，但生产构建仍走 Rollup，且与 webpack 配置心智差异大，存量项目迁移成本高；
- esbuild 极快，但不兼容 webpack loader/plugin，生态无法直接复用；
- Rspack 选择“兼容 webpack 配置 + Rust 引擎”，把迁移成本压到最低，同时吃满多核性能。
简单说，如果你手上是几十万行、几百个模块的 webpack 老项目，又想要 Vite 级别的开发体验，Rspack 几乎是当下最平滑的那条路。关于构建工具这些年怎么演进的，可以回顾这篇 前端构建工具演进。它也解释了为什么 Rust / Go 重写前端工具链成了 2023 年之后的行业共识。
二、5 分钟跑通第一个 Rspack 项目
Rspack 提供了独立的 CLI 与配置，安装即用。下面是最精简的起步流程。
1. 安装与初始化
npm create rspack@latest my-app
cd my-app
npm install
npm run dev # 启动开发服务器，HMR 默认开启
npm run build # 生产构建，输出到 dist/如果你已有项目，也可以直接装上核心包手动接入：
npm install -D @rspack/core @rspack/cli2. 最小 rspack.config.js
const path = require('path');
module.exports = {
entry: './src/index.js',
output: {
path: path.resolve(__dirname, 'dist'),
filename: 'bundle.js',
},
module: {
rules: [
{ test: /\.js$/, use: 'builtin:swc-loader', options: { jsc: { parser: { syntax: 'ecmascript' } } } },
{ test: /\.css$/, use: ['builtin:lightningcss-loader'] },
],
},
devServer: { port: 8080, hot: true },
};注意 builtin:swc-loader 是 Rspack 内置的 Rust 转译器，替代 babel，速度提升一个数量级。开发服务器与 webpack-dev-server 配置高度对齐，存量配置几乎不用改。对于 TS 项目，只需把 syntax 换成 typescript 并打开 decorators 等开关即可，swc 会自动处理类型擦除。
三、从 Webpack 平滑迁移
Rspack 的设计目标就是“低摩擦迁移”。它复用了 webpack 的 resolver、模块图与插件接口，绝大多数 webpack 配置项可以直接复用。这意味着你不必推倒重来，而是渐进式地把构建引擎从 Node 换成 Rust。
1. 配置项兼容度
| 能力 | webpack | Rspack | 迁移成本 |
| entry / output | ✅ | ✅ 一致 | 几乎 0 |
| loader 机制 | ✅ | ✅ 兼容 | 低（少数 loader 需替换） |
| plugin 接口 | ✅ | ✅ Tapable 兼容 | 低 |
| JS 转译 | babel-loader | builtin:swc-loader | 替换 loader |
| CSS 处理 | css-loader | builtin:lightningcss | 替换 loader |
2. 迁移三步法
- 备份 webpack.config.js，把
require('webpack')换成require('@rspack/core')； - 将 babel-loader 改为 builtin:swc-loader，删除 .babelrc 中仅用于构建的部分；
- 用
rspack build跑一次，对照产物体积与控制台告警逐个处理不兼容 loader。
社区还提供了官方的 @rspack/cli 兼容层与 webpack-to-rspack codemod，可以自动改写大部分配置。在 前端工程化与 Monorepo 这类多包仓库里，Rspack 的并行编译优势会被进一步放大——每个子包可以同时被不同线程处理，整体构建时间接近各子包的“最长路径”而非“总和”。
四、用 Rsbuild 把配置降到零
如果连 rspack.config.js 都不想写，可以上层使用 Rsbuild——基于 Rspack 的零配置构建工具，类似 Vite 的开箱即用体验，但底层是 Rust 引擎。它把“约定优于配置”做到极致，你只需要声明框架与入口。
npm install -D @rsbuild/core @rsbuild/plugin-react
// rsbuild.config.ts
import { defineConfig } from '@rsbuild/core';
import { pluginReact } from '@rsbuild/plugin-react';
export default defineConfig({
plugins: [pluginReact()],
server: { port: 3000 },
build: { sourceMap: { js: 'hidden' } },
});Rsbuild 内置了 React/Vue/TS/SWC 等主流预设，一条命令启动，特别适合新项目或对配置不敏感的中小型应用。而如果你追求极致的体积与运行时性能，可以参考 前端性能优化 中的实践进一步调优，例如按路由拆分 chunk、开启 Brotli 压缩、消除重复依赖等。
五、性能实测：Rspack 到底快多少
我们在一个约 1200 个模块、TS + React 的真实仓库里对比了三种方案的冷启动与增量构建（数值为多次均值，仅作量级参考，实际表现与机器核数强相关）。
| 方案 | 冷启动 | HMR 增量 | 生产构建 |
| webpack 5 | 28.4s | 1.8s | 41.2s |
| Vite（esbuild 预构建） | 3.1s | 0.2s | 22.6s（Rollup） |
| Rspack | 2.6s | 0.15s | 9.8s |
可以看到，Rspack 在保持 webpack 生态的同时，把冷启动压到 3 秒以内、生产构建缩短到原来的四分之一左右。这背后是 Rust 的多线程并行解析与 SWC 的高性能转译。结合 Bun 这类极速运行时做脚本与测试，整体研发吞吐还能再上一个台阶。值得一提的是，Rspack 的 HMR 增量几乎恒定，不会因为模块增多而明显变慢——这正是 Rust 引擎相比 Node 单线程最直观的优势。
六、模块联邦与微前端：Rspack 的进阶玩法
当你的系统演进到微前端架构，模块联邦（Module Federation）几乎是标配。Rspack 提供了 Rspack 原生模块联邦插件，兼容 webpack 的模块联邦协议，因此新旧构建产物可以互相加载，非常适合灰度迁移。
const { ModuleFederationPlugin } = require('@rspack/core').container;
new ModuleFederationPlugin({
name: 'appShell',
remotes: { cart: 'cart@https://cart.example.com/remoteEntry.js' },
shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
});在 Vue3 组合式 API 或 React 技术栈里，模块联邦让你把不同团队维护的子应用拆成独立部署单元，又能在运行时拼成同一个页面。Rspack 对该插件的并行优化，使得远端模块的预取与解析也明显快于 webpack。
七、生产落地清单与常见坑
生产检查清单
| 项目 | 建议 |
| CI 缓存 | 开启 Rspack 持久化缓存（cache.type=’filesystem’） |
| 产物分析 | 用 @rspack/plugin-react 或内置 profile 看 chunk 体积 |
| Tree Shaking | 确保 ESM 入口、避免 sideEffects 误配 |
| CSS | 优先 lightningcss 替代 postcss 链，速度更快 |
| 监控 | 接入 构建耗时打点，防止回归 |
常见坑与排障
- 某些 webpack 插件依赖 Node 单线程钩子，在 Rust 并行下会失效——改用 Rspack 官方等价插件；
- swc 默认不读 babel 的 polyfill 配置，浏览器兼容需要显式配 targets；
- Monorepo 下 resolver 别名要重新声明，否则找不到软链包；
- 大仓建议用 按路由拆分 + 模块联邦，避免单包过大。
另外要注意，Rspack 并非万能：它目前对极少数深度定制 webpack 插件（例如依赖 compilation 内部钩子顺序的插件）支持还不完善；如果你的构建链路重度依赖这类插件，建议先在独立分支验证再全量切换。对于全新的小型项目，也可以直接对比 Vite 的开发者体验，二者在开发态都很快，差异主要在生态与存量迁移成本。
总的来说，Rspack 不是又一个“重写一切”的玩具，而是一把对准 webpack 痛点的手术刀：配置兼容、迁移平滑、速度翻倍。对于还在被 webpack 慢构建折磨的团队，现在正是评估它的最佳时机。配合 VS Code 的 Rspack 插件，开发体验还能再进一步——从保存代码到页面刷新，常常快到几乎无感。
