Rspack 是 webpack 的迁移出口，远不止 Rust 速度

这张来自 Wikimedia Commons 的真实字节跳动 1733 商业空间照片适合 Rspack，因为 Rspack 起初正是对字节跳动内部大型应用构建压力的回应：漫长的生产构建、缓慢的冷启动，以及 webpack 迁移成本，让打包从工具偏好变成了基础设施问题。[1][10]

Rspack 很容易被简化成一句口号：webpack，但用 Rust。这个口号便于定位，却会妨碍采纳。这个项目重要，是因为它把前端构建速度当作兼容性问题处理，将讨论重心从纯粹性竞赛转向迁移成本。它的强承诺，是让多年积累 webpack 配置、loader、plugin、Module Federation 假设、CSS 行为和 CI 脚本的团队，先移动流水线里最慢的部分，同时保留交付系统的其余契约。[1][2][3]

起源解释了项目的形状。Rspack 自己的介绍说，它诞生于字节跳动内部的性能问题：大型单体应用已经长成复杂构建系统，生产打包常以数十分钟计，冷启动可超过数分钟。[1] 文档直接给出人的耐受阈值：一条每小时调用许多次的开发命令，如果启动时间越过 10-15 秒，就会变成生产力税；大型应用在 CI 流水线里花 20-30 分钟构建，流水线也会被拖住。[1] 玩具基准无法解释 Rspack。它真正要做的，是保留足够多的 webpack 表面，使迁移成本不吞掉速度收益。

截至 2026-07-05T05:34:31Z UTC，公开 GitHub API 显示，web-infra-dev/rspack 拥有 12,800 stars、819 forks、196 open issues，采用 MIT license，最新 push 时间为 2026-07-05T03:04:39Z。[5] release feed 显示，v2.1.2 发布于 2026-06-30，之前是 6 月 27 日的 v2.1.1 和 6 月 26 日的 v2.1.0。[6] 这些数字不能证明它适合某个特定代码库。它们说明的是，这个项目仍在快速移动，采纳它应被视为当下的工程决策，而不是一次冻结在 2024 年的 webpack 替换试验。

产品是迁移表面

Rspack 的迁移指南最能说明问题，因为它从普通 webpack 现实出发。它告诉 webpack 5 项目安装 @rspack/core，按需添加 @rspack/cli 和 @rspack/dev-server，把 webpack serve 和 webpack build 换成 rspack dev 与 rspack build，并将 webpack.config.js 改名为 rspack.config.js，除非项目传入了自定义配置路径。[2] 这段说明没有光鲜架构宣言的样子，却把采纳策略缩到最小：让操作者的心智模型保持足够接近，使性能工作可以在每个 plugin 和构建假设重新谈判之前开始。

缓存示例说明了为什么“兼容 webpack”仍然需要工程谨慎。有些缓存形态可以清楚映射，例如 memory cache 行为；但 webpack filesystem cache 需要转成 Rspack persistent cache，cache.buildDependencies 必须扁平化，cache name 和 version 语义移入 cache.version，snapshot 选项移到 cache.snapshot 下，cache 目录则移到 cache.storage.directory。[2] 忽略这些细节的迁移仍能跑起来，只是纪律不足。那会成为一个熟悉配置文件包裹下的快速 bundler，把陈旧缓存风险藏起来。

这是第一个边界条件。Rspack 最有力的位置，是团队已经拥有 webpack 形态的资产，并希望降低构建延迟，同时避免发明一套新的构建契约。当团队期待 webpack 行为中每一个未支持边角都自动消失时，它的力量会减弱。迁移单位应该是一套真实应用，带着它奇怪的 CSS、loader、动态 import、环境标志、HTML 生成、asset 路径和 plugin 链条。空白 demo 说明不了多少。

兼容性要看表格，不能靠感觉

plugin 兼容性页面是健康的，因为它具体。它区分了内置替代品、兼容 plugin、替代方案、部分兼容和不兼容。copy-webpack-plugin 有 CopyRspackPlugin；mini-css-extract-plugin 有 CssExtractRspackPlugin；tsconfig-paths-webpack-plugin 对应到 resolve.tsConfig；@sentry/webpack-plugin、webpack-bundle-analyzer 和 html-webpack-plugin 被列为兼容；其他条目，包括一些 Angular 和 docgen 相关 plugin，则标记为不兼容或部分兼容。[3]

这张表会改变团队评估 Rspack 的方式。问题不应停在抽象的“它支持 webpack 吗”。更具体的问题，是你的产品 plugin graph 落在受支持通道、替代通道，还是高风险通道。一个使用常规 React、CSS 提取、HTML 生成、bundle 分析和常见 loader 模式的产品，迁移范围相对较窄。一个依赖自定义 webpack internals、非常规 plugin hooks、Angular 专用工具或未文档化 loader 副作用的产品，在任何人承诺干净切换之前，需要先做兼容性审计。[3]

GitHub README 的功能列表从项目侧指向同一份契约：快速启动、通过增量编译支持 HMR、兼容 webpack loader 和 plugin、一等 Module Federation 支持、tree shaking 与 minification 等生产优化，以及框架无关。[5] 这些都不能替代对真实图谱的测试。它们解释的是，Rspack 的定位并非极简 greenfield bundler。它要保持快速，同时又要足够贴近 webpack 生态，让大型应用能够迁移。

独立报道通常也这样理解。AppSignal 2025 年的介绍把 Rspack 描述为一个用 Rust 编写的 JavaScript bundler，可在许多 webpack 用例中充当 drop-in replacement，并强调 HMR、生产打包和跨框架兼容性。[7] InfoQ 更早的报道则把开源发布放在字节跳动与 Valor Software 的合作中，聚焦冷启动和生产构建耗时的降低，以及 webpack interoperability 的保留。[8] 这些外部摘要最有用的地方不在单个速度宣称，而在于它们都指向同一个差异点：速度加迁移表面。

Rspack 2.1 关注输出质量，不只看秒表

2.1 release 重要，是因为它显示了项目成熟方向。标题级性能数据仍然存在：Rspack 的 benchmark 声称 production build time 在无 cache 情况下从 2.0.0 的 2.66 s 降至 2.1.0 的 2.22 s，有 cache 时从 1.36 s 降至 1.20 s，HMR 从 113 ms 降至 107 ms。[4] React Compiler 对比更尖锐：在公开 benchmark 中，通过 builtin:swc-loader 启用 Rust 版本，据称 rspack build 比 Babel 路径快 7.4x，rspack dev 快 13.5x。[4]

2.1 更值得看的部分还在速度之外。它加入了 import.meta.glob，通过 css/global 等模式改进内置 CSS 支持，为 createRequire 增加静态分析，引入 Rspack 前缀 magic comments、面向 WebAssembly 的 Source Phase Imports，以及通过 cache.maxAge 和 cache.maxVersions 自动清理 persistent cache；默认设置会保留 7 天内未访问的 cache versions，并在每个 cache directory 保留 3 个 versions。[4] 这些不是摆设。它们指向现代前端构建的实际中段：ESM/CommonJS 接缝、CSS module 作用域、cache hygiene、Wasm 加载，以及跨工具语法预期。

输出优化也是一个信号。在 2.1 中，pureFunctions 成为 production-default 行为，用于移除标记为无副作用的未使用调用；branch-aware dependency pruning 可以在 inline constants 让某个 branch 无法抵达时，丢弃 inactive dynamic-import branches；branch-aware ESM export checks 则减少 guarded namespace access 周围的误报 warning。[4] 这些变化很细。它们重要，是因为前端构建性能已经不再只关乎 compiler 走过 module graph 的速度，也关乎它能多准确地判断哪些内容不该进入最终 graph。

Rspack 真正的工程赌注就在这里显现。Rust 给了它提速空间，兼容性则限制它重新解释旧模式的力度。打破常见 webpack 预期的 bundler 会赢下 benchmark，却输掉生产迁移。永远复制每一种历史行为的 bundler 会变成更快的 webpack，同时停止成为更好的 toolchain。Rspack 2.x 正在这两种失败之间前进：保留生态桥梁，同时在现代 JavaScript、React Compiler、TypeScript Go 和 ESM 让旧契约变得过于昂贵的地方，调整 defaults 和 analysis。[4]

Rstack 把 bundler 推到工具链中心

首页现在围绕 Rspack 呈现出更宽的 Rstack toolchain：用于 out-of-the-box builds 的 Rsbuild、用于 libraries 的 Rslib、用于 documentation sites 的 Rspress、用于 build analysis 的 Rsdoctor、用于 testing 的 Rstest，以及指向 linting 和 type-checking 的 Rslint。[9] 这一点重要，因为在大型前端资产中，bundling 很少是唯一瓶颈。类型检查、测试、文档构建、库打包、bundle 分析和 CI 诊断，往往处在同一个反馈回路里。

对采纳者来说，这个更宽的 stack 同时带来杠杆和风险。杠杆很明显：团队可以先在 webpack 形态的应用里使用 Rspack，之后再决定 Rsbuild、Rslib 或 Rsdoctor 是否能降低相邻摩擦。风险则是还没证明 bundler 边界，就先采纳整个生态。Rspack 应该先靠自身进入系统。如果它稳定了构建时间并保留行为，周边工具就会成为可选的整合路线，而不是被迫的平台重写。

最保守的推出方式大致如下。选择一个 webpack 延迟很痛、plugin graph 有代表性的应用。冻结一个 fixture build，覆盖 production mode、development mode、CSS extraction、dynamic imports、environment flags、HTML output、使用时的 Module Federation、source maps 和 asset handling。让 webpack 与 Rspack 并行运行。比较 output size、chunk names、public paths、sourcemap usability、HMR behavior、cache invalidation 和 CI wall-clock time。完成这些之后，再决定是否扩大迁移。[2][3][4]

团队还应该在 pilot 开始前设定 failure budget。如果关键 plugin 不兼容，如果某个 loader 依赖 webpack internals，如果 output 差异影响 caching 或 monitoring，或者团队解释不清 persistent-cache behavior，就暂停。成功条件不应写成“Rspack 跑起来了”。成功条件应写成：“Rspack 让构建更快，同时交付契约仍然可理解。”

Rspack 适合的位置

Rspack 最适合那些已经付出真实 webpack 税的前端资产：大型 React 或多框架应用、bundling 阻塞 merge throughput 的 CI 流水线、惩罚 context switches 的 dev server、Module Federation 系统，以及 webpack 投入太深而无法证明 greenfield rewrite 合理性的团队。它也适合愿意把 compatibility matrix 纳入迁移规划，而不是靠偶然发现 plugin 缺口的组织。[1][2][3]

对于 build time 已经可以忽略的小型应用、能够干净转向更简单 Vite/Rollup-style stack 的项目，或者希望获得速度升级却不愿维护 test fixtures 的团队，它的适配会更弱。它也不能替代 bundle 纪律。更快的 compiler 可以在一段时间内遮住松散的 dependency growth，但它无法阻止产品团队因为方便的 barrel files 导入整个库，也无法替他们拆分本该拆出的 code paths。[4]

因此，最好的读法既克制又有力度。Rspack 的重要性不来自 Rust 让构建工具显得时髦，而来自它提供了一条离开 webpack 慢速部分的现实迁移出口，同时承认 webpack 生态已经教会前端世界：一个 bundler 想要存活在生产环境里，必须承受大量古怪案例。它的价值就在边界上：足够熟悉，所以可以迁移；足够快，所以值得迁移；现在也足够成熟，让输出质量和 cache hygiene 进入同一个故事。

cronfeed.work