从 5.6s 到 1.4s从 192 个依赖砍到 1 个Rspack 2.0 不只是更快的 webpack了。Rspack 2.0 在 7 月 29 日正式发布。不只是字节跳动的 webpack 替代品。这次 2.0 的核心变化可以浓缩成三句话性能翻倍——相比 1.0构建速度最多快 100%10000 组件项目缓存构建从 5.6s 降到 1.4s依赖瘦身——rspack/dev-server依赖从 192 个砍到 1 个安装体积减少 90%全面 ESM 化——核心包转为纯 ESM支持 RSC、import defer 等现代特性总结就一句它不再满足于只做更快的 webpack开始走自己的路了。1. Rspack 2.0 到底更新了什么1.1 性能提升先看一组最直观的基准测试数据来源rspack-react-10k-benchmark测试环境M3 Pro 芯片、32GB 内存、NVMe SSD、Node.js 22.12版本生产构建无缓存生产构建有缓存HMR 热更新Rspack 1.05.6s5.6s128msRspack 1.73.6s2.2s134msRspack 2.03.1s1.4s118ms简单来说启用持久化缓存后10000 个组件的 React 项目生产构建只要 1.4 秒。这些数字都传递了什么信息呢未做深度性能优化、未开启持久化缓存的原生 webpack 5同规模项目生产构建通常在 30-60 秒量级。Rspack 2.0 无缓存首次构建约为 webpack 的 10-20 倍持久化缓存命中场景约为 webpack 缓存构建的 20 倍以上。除了构建速度2.0 还在缓存场景做了两个优化SWC 压缩器的压缩结果可以缓存复用命中缓存时构建性能再提升约 50%启用缓存后内存占用下降了 20%同项目在 webpack 5 下的生产构建时间约为 35-45 秒首次/ 28-35 秒缓存命中。Rspack 2.0 缓存构建 1.4 秒约为 webpack 缓存构建的20-25 倍。CI 环境的缓存陷阱持久化缓存依赖package-lock.json和环境变量来生成缓存 key。如果 CI 构建每次都是全新环境且未持久化node_modules/.cache目录缓存命中率几乎为零反而会因磁盘读写拖慢构建。建议通过 CI 缓存能力持久化缓存目录或固定RSPACK_CONFIG_CACHE_KEY环境变量提升命中率。1.2 依赖大瘦身从 192 到 1这个变化在 Hacker News 上反而比性能数据更火。包1.x 依赖数2.0 依赖数安装体积rspack/dev-server192115MB → 1.4MBrspack/core81—rspack/cli—0零依赖—它是怎么做到的呢用connect-next替代 Express——开发服务器的中间件模型用 Connect 就够了不需要完整的 Express依赖打包进发布产物——把非核心依赖直接打包进 npm 包由 Rspack 统一控制版本避免供应链风险。不过是两面性的这种「vendor 化」策略意味着你无法通过npm overrides直接升级传递依赖版本来修复 CVE 漏洞需依赖官方发版patch-package虽可对打包后的产物生效但维护成本极高不推荐企业级项目使用。大型企业需要评估内部安全扫描策略是否兼容这种方式用 Node.js 20 原生 API——比如用内置的styleText替代picocolors非核心依赖改为可选——比如module-federation/runtime-tools只在使用模块联邦插件时才需要手动安装有位评论者说得挺好与性能数据相比依赖项减少的数字更让我印象深刻——这是一种理念的转变而不仅仅是基准测试。1.3 纯 ESM 核心Rspack 2.0 的核心包rspack/core、rspack/cli、rspack/dev-server、rspack/plugin-react-refresh全部转为纯 ESM 包发布移除了 CommonJS 构建产物。那么问题来了我的现有项目还在用 CommonJS会不会挂答案是在 Node.js 版本符合要求且未引入含顶层 await 的 ESM 依赖的前提下大概率不会。Node.js 22.12 已稳定支持 CommonJS 中通过require()加载 ESM 模块require(esm)20.19 为实验性支持。因此大多数通过 JavaScript API 使用 Rspack 的项目无需修改代码。但有一点需要注意如果 ESM 模块内部使用了顶层awaitTop-level awaitrequire()会直接抛出ERR_REQUIRE_ASYNC_MODULE错误没法绕过。目前 Rspack 2.0 自身没有使用顶层 await但如果你在配置文件中引入了含顶层 await 的第三方 ESM 依赖CJS 项目就会挂示例// ❌ 会报错CJS 配置文件引入了含顶层 await 的 ESM 依赖// rspack.config.js (CommonJS)constsomeEsmPkgrequire(some-esm-pkg-with-tla);// 抛出 ERR_REQUIRE_ASYNC_MODULE// ✅ 修复方案1将配置文件改为 rspack.config.mjsimportsomeEsmPkgfromsome-esm-pkg-with-tla;// ✅ 修复方案2package.json 中设置 type: module另外说一下这里说的是 Rspack 自己的包变成 ESM不影响你用 Rspack 构建 CommonJS 产物的能力。构建行为和配置方式跟以前一样。1.4 产物优化tree shaking 全面加强Rspack 2.0 在静态分析能力上做了大幅增强1. CommonJS require 解构也能 tree shake 了// ✅ 支持 tree shake静态解构const{bar}require(./foo);// ❌ 不支持 tree shake运行时属性访问constfoorequire(./foo);constbarfoo.bar;// ❌ 不支持 tree shake条件导出module.exportsprocess.env.NODE_ENVdevelopment?devApi:prodApi;这个优化依赖于exports对象的静态可分析性。如果你的 CJS 模块存在运行时条件导出或动态属性赋值module.exports[prop Name]Rspack 会保守起见保留整个模块。建议在这种情况显式声明sideEffects: false来辅助判断。2. 构建器注解#__NO_SIDE_EFFECTS__/*#__NO_SIDE_EFFECTS__*/exportfunctionjoin(a,b){return${a}-${b};}import{join}from./utils;join(btn,primary);// 返回值没被使用 → 整个调用会被移除这个功能目前还是实验性的需要通过experiments.pureFunctions开启后续版本会默认开启。顺便说下它和/*#__PURE__*/的区别——可能很多人更熟悉后者。/*#__PURE__*/作用于函数调用标记某一次具体调用无副作用而#__NO_SIDE_EFFECTS__作用于函数声明本身标记整个函数无副作用。后者更强大即使跨模块引用且未使用返回值Rspack 也能安全删除整个函数调用。以前要做到这件事得靠webpack-deep-scope-plugin这类第三方插件现在原生支持了。3. 模块联邦Module Federation tree shaking以前用模块联邦的shared声明依赖运行时会加载完整包。现在可以开启treeShaking选项只打包实际用到的导出// 方式1运行时自动推断推荐无需手动声明用到的导出newrspack.container.ModuleFederationPlugin({shared:{lodash-es:{singleton:true,treeShaking:{mode:runtime-infer},},},})// 方式2手动指定使用的导出确定性更高newrspack.container.ModuleFederationPlugin({shared:{lodash-es:{singleton:true,treeShaking:{mode:manual,usedExports:[debounce],// 只打包 debounce},},},})1.5 React Server Components 实验性支持Rspack 2.0 开始提供 RSC 的底层构建支持支持use client声明和模块/函数级别的use server声明编译期检查违反 RSC 规范的 API 调用服务端和客户端组件的 CSS 收集与注入同时支持服务端和客户端组件的 HMR如何手动启用需要设置experiments.rsc: true并配置resolve.conditionNames包含react-server条件导出确保服务端构建能正确解析 RSC 专用入口。更推荐通过rsbuild-plugin-rsc开箱即用插件会自动处理 client/server 双端构建配置的分裂避免你手写两套配置。能力边界当前仅支持基础的 RSC 构建链路不支持 Streaming SSR、Server Actions 等进阶特性。仅推荐与 Modern.js、TanStack Start 等上层框架搭配使用不建议手动从零配置。目前 Modern.js 已基于 Rspack 提供了完整的 RSC 支持Rspack 也在跟 TanStack 团队合作后续会支持 TanStack Start。1.6 其他值得关注的新特性特性说明import.meta支持保留无法识别的import.meta属性不再替换为undefinedimport defer支持stage-3 提案延后模块求值TS 5.9 已支持modern-module库构建生成更适合库发布的 ESM 产物保留目录结构#/子路径别名直接用package.json的imports字段不用额外配 alias简化 target 配置顶层target自动继承到 loader 和压缩插件不用重复声明简化 swc-loader 配置detectSyntax: auto自动推断语法一条规则覆盖所有文件类型哈希模块 IDoptimization.moduleIds: hashed更短更稳定的模块 ID代码分割改进支持splitChunks.enforceSizeThreshold强制拆分大 chunk2. Why为什么需要 Rspack 2.02.1 webpack 的痛Vite 解决不了的部分前端构建工具的格局在 2026 年变成了三足鼎立Vite 在中小型项目上依然是王者——零配置启动、HMR 极快、插件生态丰富。到 2026 年 Vite 的生产构建底层已切换至 RolldownRust大型项目的构建性能也有了质变。但 Rspack 在两个场景上依然有不可替代性一是微前端主应用的子应用加载webpack 的ModuleFederationPlugin生态深度依赖二是需要深度定制 webpack compiler hooks 的企业级项目。Vite 的生产构建走 Rollup/Rolldown 路线跟 webpack 的 loader/plugin 生态天然不兼容这不是性能问题是路线问题。Rspack 的核心差异化就一句话让 webpack 生态的项目低成本获得 Rust 级别的性能。这不是一个小市场。全球有海量的 webpack 项目它们的配置文件、自定义 loader、公司内部的插件——这些东西不是想扔就能扔的。Rspack 对 webpack 常用 API 与主流生态有 95% 左右的兼容度意味着大多数项目改个包名就能跑起来。2.2 1.x 阶段的回顾目标达成Rspack 1.0 在 2024 年 8 月发布设定的目标是在保持 webpack 兼容的前提下实现 10 倍性能提升。从 1.0 到 2.0 发布的近两年间做到了什么周下载量从 10 万增长到500 万——50 倍增长陆续引入增量构建、按需编译、持久化缓存、常量折叠Constant Folding、桶文件Barrel 文件即 index 统一导出文件优化等特性围绕 Rspack 打造了完整工具链 RstackRsbuild、Rslib、Rstest、Rspress、Rsdoctor、Rslint社区支持Angular、Nuxt、Next.js、Storybook、Docusaurus、Modern.js 等框架已提供 Rspack 适配2.3 为什么要搞 2.0Rspack 团队自己说得很直白“Rspack 的目标不只是成为一个「更快的 webpack」。在 1.x 阶段我们有意让 Rspack 的 API 和默认值与 webpack 5 保持一致这是为了帮助现有项目低成本迁移。但随着 JavaScript 模块规范和生态的发展一些历史设计已不再适合作为当下的默认选择。”1.x 是长得像 webpack来吸引你迁移2.0 开始做自己。2.0 的 ESM 化、RSC 支持、产物优化、配置简化——这些都不是 webpack 会做的事情。Rspack 在保持兼容的前提下开始引入更符合 2026 年 JavaScript 生态的默认行为。3. 怎么用上 Rspack 2.03.1 新项目直接用Rsbuild如果你是首次使用 Rspack推荐直接用 RsbuildRspack 驱动的开箱即用构建工具npmcreate rsbuildlatestRsbuild 2.0 已经跟 Rspack 2.0 同步发布开箱即用不需要折腾配置。3.2 从 Rspack 1.x 升级第一步升级依赖{devDependencies:{rspack/core:^2.0.0,rspack/cli:^2.0.0,rspack/dev-server:^2.0.0,rspack/plugin-react-refresh:^2.0.0}}第二步确认 Node.js 版本Rspack 2.0 要求 Node.js 20.19 或 22.12不再支持 Node.js 18。node-v# 如果低于 20.19先升级 Node.js第三步处理 Breaking Changes主要的破坏性变更变更影响解决方案移除module.unsafeCache缓存配置需调整用cache.type: persistent替代rspack/cli不再默认依赖rspack/dev-serverrspack serve命令需要手动安装 dev-servernpm add rspack/dev-server -Dresolve.exportsPresence默认值从warn改为error导出不存在时直接报错⚠️ 最容易导致 CI 构建失败的破坏性变更许多第三方库的exports字段书写不规范会被误杀。升级后如果构建失败可在resolve.exportsPresence设为warn降级为警告不中断构建builtin:swc-loader不再读.swcrcSWC 配置需迁移到 loader options把配置移到rspack.config.mjsoutput.chunkLoadingGlobal默认值变更chunk 全局变量名从webpackChunk变为rspackChunk如有依赖可显式配置webpack-bundler-analyzer被移除--analyze参数失效改用 Rsdoctoroutput.libraryTarget等配置迁移库构建配置语法变更迁移到output.library.typedevServer.hot默认值变更热更新默认不再自动开启需手动配置devServer.hot: true否则升级后 HMR 失效统计输出stats配置重构部分 webpack 兼容的 stats 字段被移除自定义日志输出需适配新格式resolve.exportsPresence降级示例exportdefaultdefineConfig({resolve:{exportsPresence:warn},});第四步可选用 Agent 辅助迁移如果你在用 Coding Agent比如 Cursor、Claude Code 等可以安装 Rspack 官方的迁移 Skillnpx skillsaddrstackjs/agent-skills--skillrspack-v2-upgrade装好后让 Agent 帮你完成升级通常比手动改更高效。3.3 从 webpack 迁移如果你还在用 webpackRspack 的迁移路径已经非常成熟了。核心步骤# 1. 安装 Rsbuild最简路径npmcreate rsbuildlatest# 2. 选择 Convert from webpack 模式# Rsbuild 会自动尝试转换你的 webpack.config.js或者手动迁移importpathfromnode:path;import{fileURLToPath}fromnode:url;import{defineConfig}fromrspack/core;// 2.0 推荐 ESM 配置文件不再默认有 __dirname需手动声明const__dirnamepath.dirname(fileURLToPath(import.meta.url));exportdefaultdefineConfig({entry:./src/index.js,output:{path:path.resolve(__dirname,./dist),// 必须使用绝对路径},module:{rules:[{test:/\.(?:js|mjs|jsx|ts|tsx)$/,use:{loader:builtin:swc-loader,options:{// 2.0 新特性自动推断语法替代手写 syntax jsx/tsx 布尔值detectSyntax:auto,jsc:{transform:{react:{runtime:automatic,},},},},},},],},});2.0 新增的detectSyntax: auto大幅简化了多文件类型的 loader 配置以前要写多条 rules 分别处理.js、.jsx、.ts、.tsx还要手动指定jsc.parser.syntax、jsx、tsx等选项现在一条规则全搞定根据文件扩展名自动推断该用哪种语法解析。注意output.path必须传绝对路径直接写相对路径在 ESM 配置文件下会报错。因为 2.0 推荐用 ESM 配置文件不再默认有__dirname需要通过fileURLToPath手动声明——这是很多用户升级会踩的坑。3.4 从 webpack 迁移要注意什么需要注意的是95% 兼容主要覆盖常用 API 与主流生态深度定制的项目迁移仍可能遇到兼容性问题。几个常见问题1. 自定义 webpack 插件如果你的项目有自己写的 webpack 插件需要检查是否用到了 Rspack 未实现的 API。大部分插件的 tapable hooks 都是兼容的但一些边缘 API 可能没覆盖。2. 特定 loader 兼容性大部分常用 loaderbabel-loader、css-loader、style-loader、postcss-loader都是兼容的。但一些小众 loader 可能有问题需要在 Plugin 兼容列表 里查一下。3. 模块联邦Rspack 支持模块联邦但module-federation/runtime-tools在 2.0 中变成了可选依赖。如果你用了模块联邦需要手动安装npmaddmodule-federation/runtime-tools4. 产物验证与灰度方案大型项目迁移最关心风险控制建议分阶段推进开发环境先切——先在开发环境切换到 Rspack验证 HMR、代理、静态资源等基础功能生产环境双构建对比——同时跑 webpack 和 Rspack 生产构建对比产物体积、sourcemap、核心功能回归逐步全量——确认无差异后逐步将 CI 流水线切换到 Rspack4. 该选谁维度Rspack 2.0ViteTurbopack底层语言RustRust (Rolldown 生产构建)Rustwebpack 兼容⭐⭐⭐⭐⭐ (常用 API ~95%)❌❌开发体验⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐ (仅 Next.js)大型项目构建⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐产物质量 / Tree Shaking⭐⭐⭐⭐⭐ (CJS ESM 均强)⭐⭐⭐⭐⭐ (纯 ESM 项目上限更高CJS 兼容项目弱于 Rspack)⭐⭐⭐⭐生态成熟度⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐RSC 支持✅ (实验性基础链路)✅ (通过框架)✅ (Next.js)适用场景webpack 迁移 / 大型项目中小型 SPANext.js 项目维护方字节跳动VoidZero (尤雨溪)Vercel并不是说 Rolldown 跑不动大项目它在底层性能上已经足够优秀。差异在于生态兼容性Vite 的产物构建走 Rollup/Rolldown 链路无法直接复用 webpack 的 loader 和插件。如果你的大型项目重度依赖 webpack 生态比如自定义 compiler hooks、特定的 webpack loaderRspack 是更平滑的选择。一个比较务实的选型原则新项目中小型 SPA→ Vite开发体验最好Rolldown 核心已经成熟webpack 存量项目→ Rspack迁移成本最低常用 API 95% 兼容Next.js 项目→ Turbopack原生集成Next.js 专属第一公民微前端 / 深度定制 webpack hooks→ RspackModuleFederation 和 compiler hooks 生态不可替代不确定 / 想留后路→ Rspack因为它的 webpack 兼容性给你最大的退路5. QAQ1: Rspack 和 webpack 的核心区别是什么核心区别是底层实现语言。webpack 用 JavaScript 编写受限于 Node.js 单线程模型和 V8 引擎的 GC 压力Rspack 用 Rust 编写核心利用 Rust 的内存安全、零成本抽象和多线程能力。性能方面无缓存首次构建约为 webpack 的 5-10 倍持久化缓存命中场景可达 20 倍以上。同时 Rspack 对 webpack 常用 API 与主流生态有约 95% 的兼容度大幅降低迁移成本。Q2: Rspack 2.0 转为纯 ESM 包对使用者有什么影响对大多数项目没有影响。Node.js 22.12 已稳定支持 CommonJS 中通过require()加载 ESM 模块20.19 为实验性支持。所以即使你的项目是 CommonJS 的在符合 Node 版本要求的前提下也能正常使用 Rspack 2.0。⚠️ 但有一个边界情况如果 ESM 模块内部使用了顶层 awaitTop-level awaitrequire()会直接抛出ERR_REQUIRE_ASYNC_MODULE错误无法绕过。目前 Rspack 2.0 核心包自身没有使用顶层 await但如果你在配置文件中引入的第三方 ESM 依赖含有顶层 awaitCJS 项目就会挂掉。解决方案把rspack.config.js改名为rspack.config.mjs或在package.json中设置type: module将项目切换为 ESM 模式。另外Rspack 2.0 不再支持 Node.js 18最低要求 20.19 或 22.12。Q3: 什么是#__NO_SIDE_EFFECTS__注解它解决了什么问题这是构建器注解Bundler Annotations规范中定义的注解用于将函数标记为无副作用。当被标记函数的调用返回值未被使用时tree shaking 可以安全移除该调用。这解决了一个长期问题跨模块的函数调用即使返回值没被使用因为函数体可能有副作用比如修改全局变量、发请求打包工具不敢删。有了这个注解打包工具就知道可以安全删除。Q4: Rspack 2.0 的依赖瘦身为什么重要两个原因。第一依赖越少安装越快磁盘占用越小——rspack/dev-server从 15MB 降到 1.4MB 是实打实的体感提升。第二依赖越少供应链风险越低。npm 生态中一个传递依赖被投毒或意外破坏的事件并不罕见。Rspack 通过把依赖打包进发布产物vendor 化、用 Node.js 原生 API 替代第三方包等方式大幅降低了这种风险。但要注意vendor 化意味着你无法通过npm overrides直接升级传递依赖版本来修复 CVE 漏洞需依赖官方发版patch-package虽可对打包后的产物生效但维护成本极高不推荐企业级项目使用。Q5: 在什么场景下应该选择 Rspack 而不是 Vite两个典型场景1有大量 webpack 存量代码——包括自定义 loader、插件、配置文件或重度依赖 webpack 特有的能力如模块联邦、特定的 compiler hooks迁移到 Vite 意味着重写整个构建链路成本远高于切换到 Rspack2微前端主应用——需要与多个基于 webpack 构建的子应用协同Rspack 的模块联邦生态兼容性是刚需。反之如果是从零开始的中小型 SPA不涉及 webpack 历史包袱Vite 的零配置开发体验依然是首选。参考资料Rspack 2.0 发布公告 - 官方博客Rspack 2.0 升级指南InfoQ: RSPack 2.0 性能提升、更精简的依赖项和 ESM 核心rspack-react-10k-benchmark以上就是本节的全部内容如果你觉得有收获欢迎关注持续分享好文下期见
Rspack 2.0 正式发布 — 前端构建工具格局再变天
从 5.6s 到 1.4s从 192 个依赖砍到 1 个Rspack 2.0 不只是更快的 webpack了。Rspack 2.0 在 7 月 29 日正式发布。不只是字节跳动的 webpack 替代品。这次 2.0 的核心变化可以浓缩成三句话性能翻倍——相比 1.0构建速度最多快 100%10000 组件项目缓存构建从 5.6s 降到 1.4s依赖瘦身——rspack/dev-server依赖从 192 个砍到 1 个安装体积减少 90%全面 ESM 化——核心包转为纯 ESM支持 RSC、import defer 等现代特性总结就一句它不再满足于只做更快的 webpack开始走自己的路了。1. Rspack 2.0 到底更新了什么1.1 性能提升先看一组最直观的基准测试数据来源rspack-react-10k-benchmark测试环境M3 Pro 芯片、32GB 内存、NVMe SSD、Node.js 22.12版本生产构建无缓存生产构建有缓存HMR 热更新Rspack 1.05.6s5.6s128msRspack 1.73.6s2.2s134msRspack 2.03.1s1.4s118ms简单来说启用持久化缓存后10000 个组件的 React 项目生产构建只要 1.4 秒。这些数字都传递了什么信息呢未做深度性能优化、未开启持久化缓存的原生 webpack 5同规模项目生产构建通常在 30-60 秒量级。Rspack 2.0 无缓存首次构建约为 webpack 的 10-20 倍持久化缓存命中场景约为 webpack 缓存构建的 20 倍以上。除了构建速度2.0 还在缓存场景做了两个优化SWC 压缩器的压缩结果可以缓存复用命中缓存时构建性能再提升约 50%启用缓存后内存占用下降了 20%同项目在 webpack 5 下的生产构建时间约为 35-45 秒首次/ 28-35 秒缓存命中。Rspack 2.0 缓存构建 1.4 秒约为 webpack 缓存构建的20-25 倍。CI 环境的缓存陷阱持久化缓存依赖package-lock.json和环境变量来生成缓存 key。如果 CI 构建每次都是全新环境且未持久化node_modules/.cache目录缓存命中率几乎为零反而会因磁盘读写拖慢构建。建议通过 CI 缓存能力持久化缓存目录或固定RSPACK_CONFIG_CACHE_KEY环境变量提升命中率。1.2 依赖大瘦身从 192 到 1这个变化在 Hacker News 上反而比性能数据更火。包1.x 依赖数2.0 依赖数安装体积rspack/dev-server192115MB → 1.4MBrspack/core81—rspack/cli—0零依赖—它是怎么做到的呢用connect-next替代 Express——开发服务器的中间件模型用 Connect 就够了不需要完整的 Express依赖打包进发布产物——把非核心依赖直接打包进 npm 包由 Rspack 统一控制版本避免供应链风险。不过是两面性的这种「vendor 化」策略意味着你无法通过npm overrides直接升级传递依赖版本来修复 CVE 漏洞需依赖官方发版patch-package虽可对打包后的产物生效但维护成本极高不推荐企业级项目使用。大型企业需要评估内部安全扫描策略是否兼容这种方式用 Node.js 20 原生 API——比如用内置的styleText替代picocolors非核心依赖改为可选——比如module-federation/runtime-tools只在使用模块联邦插件时才需要手动安装有位评论者说得挺好与性能数据相比依赖项减少的数字更让我印象深刻——这是一种理念的转变而不仅仅是基准测试。1.3 纯 ESM 核心Rspack 2.0 的核心包rspack/core、rspack/cli、rspack/dev-server、rspack/plugin-react-refresh全部转为纯 ESM 包发布移除了 CommonJS 构建产物。那么问题来了我的现有项目还在用 CommonJS会不会挂答案是在 Node.js 版本符合要求且未引入含顶层 await 的 ESM 依赖的前提下大概率不会。Node.js 22.12 已稳定支持 CommonJS 中通过require()加载 ESM 模块require(esm)20.19 为实验性支持。因此大多数通过 JavaScript API 使用 Rspack 的项目无需修改代码。但有一点需要注意如果 ESM 模块内部使用了顶层awaitTop-level awaitrequire()会直接抛出ERR_REQUIRE_ASYNC_MODULE错误没法绕过。目前 Rspack 2.0 自身没有使用顶层 await但如果你在配置文件中引入了含顶层 await 的第三方 ESM 依赖CJS 项目就会挂示例// ❌ 会报错CJS 配置文件引入了含顶层 await 的 ESM 依赖// rspack.config.js (CommonJS)constsomeEsmPkgrequire(some-esm-pkg-with-tla);// 抛出 ERR_REQUIRE_ASYNC_MODULE// ✅ 修复方案1将配置文件改为 rspack.config.mjsimportsomeEsmPkgfromsome-esm-pkg-with-tla;// ✅ 修复方案2package.json 中设置 type: module另外说一下这里说的是 Rspack 自己的包变成 ESM不影响你用 Rspack 构建 CommonJS 产物的能力。构建行为和配置方式跟以前一样。1.4 产物优化tree shaking 全面加强Rspack 2.0 在静态分析能力上做了大幅增强1. CommonJS require 解构也能 tree shake 了// ✅ 支持 tree shake静态解构const{bar}require(./foo);// ❌ 不支持 tree shake运行时属性访问constfoorequire(./foo);constbarfoo.bar;// ❌ 不支持 tree shake条件导出module.exportsprocess.env.NODE_ENVdevelopment?devApi:prodApi;这个优化依赖于exports对象的静态可分析性。如果你的 CJS 模块存在运行时条件导出或动态属性赋值module.exports[prop Name]Rspack 会保守起见保留整个模块。建议在这种情况显式声明sideEffects: false来辅助判断。2. 构建器注解#__NO_SIDE_EFFECTS__/*#__NO_SIDE_EFFECTS__*/exportfunctionjoin(a,b){return${a}-${b};}import{join}from./utils;join(btn,primary);// 返回值没被使用 → 整个调用会被移除这个功能目前还是实验性的需要通过experiments.pureFunctions开启后续版本会默认开启。顺便说下它和/*#__PURE__*/的区别——可能很多人更熟悉后者。/*#__PURE__*/作用于函数调用标记某一次具体调用无副作用而#__NO_SIDE_EFFECTS__作用于函数声明本身标记整个函数无副作用。后者更强大即使跨模块引用且未使用返回值Rspack 也能安全删除整个函数调用。以前要做到这件事得靠webpack-deep-scope-plugin这类第三方插件现在原生支持了。3. 模块联邦Module Federation tree shaking以前用模块联邦的shared声明依赖运行时会加载完整包。现在可以开启treeShaking选项只打包实际用到的导出// 方式1运行时自动推断推荐无需手动声明用到的导出newrspack.container.ModuleFederationPlugin({shared:{lodash-es:{singleton:true,treeShaking:{mode:runtime-infer},},},})// 方式2手动指定使用的导出确定性更高newrspack.container.ModuleFederationPlugin({shared:{lodash-es:{singleton:true,treeShaking:{mode:manual,usedExports:[debounce],// 只打包 debounce},},},})1.5 React Server Components 实验性支持Rspack 2.0 开始提供 RSC 的底层构建支持支持use client声明和模块/函数级别的use server声明编译期检查违反 RSC 规范的 API 调用服务端和客户端组件的 CSS 收集与注入同时支持服务端和客户端组件的 HMR如何手动启用需要设置experiments.rsc: true并配置resolve.conditionNames包含react-server条件导出确保服务端构建能正确解析 RSC 专用入口。更推荐通过rsbuild-plugin-rsc开箱即用插件会自动处理 client/server 双端构建配置的分裂避免你手写两套配置。能力边界当前仅支持基础的 RSC 构建链路不支持 Streaming SSR、Server Actions 等进阶特性。仅推荐与 Modern.js、TanStack Start 等上层框架搭配使用不建议手动从零配置。目前 Modern.js 已基于 Rspack 提供了完整的 RSC 支持Rspack 也在跟 TanStack 团队合作后续会支持 TanStack Start。1.6 其他值得关注的新特性特性说明import.meta支持保留无法识别的import.meta属性不再替换为undefinedimport defer支持stage-3 提案延后模块求值TS 5.9 已支持modern-module库构建生成更适合库发布的 ESM 产物保留目录结构#/子路径别名直接用package.json的imports字段不用额外配 alias简化 target 配置顶层target自动继承到 loader 和压缩插件不用重复声明简化 swc-loader 配置detectSyntax: auto自动推断语法一条规则覆盖所有文件类型哈希模块 IDoptimization.moduleIds: hashed更短更稳定的模块 ID代码分割改进支持splitChunks.enforceSizeThreshold强制拆分大 chunk2. Why为什么需要 Rspack 2.02.1 webpack 的痛Vite 解决不了的部分前端构建工具的格局在 2026 年变成了三足鼎立Vite 在中小型项目上依然是王者——零配置启动、HMR 极快、插件生态丰富。到 2026 年 Vite 的生产构建底层已切换至 RolldownRust大型项目的构建性能也有了质变。但 Rspack 在两个场景上依然有不可替代性一是微前端主应用的子应用加载webpack 的ModuleFederationPlugin生态深度依赖二是需要深度定制 webpack compiler hooks 的企业级项目。Vite 的生产构建走 Rollup/Rolldown 路线跟 webpack 的 loader/plugin 生态天然不兼容这不是性能问题是路线问题。Rspack 的核心差异化就一句话让 webpack 生态的项目低成本获得 Rust 级别的性能。这不是一个小市场。全球有海量的 webpack 项目它们的配置文件、自定义 loader、公司内部的插件——这些东西不是想扔就能扔的。Rspack 对 webpack 常用 API 与主流生态有 95% 左右的兼容度意味着大多数项目改个包名就能跑起来。2.2 1.x 阶段的回顾目标达成Rspack 1.0 在 2024 年 8 月发布设定的目标是在保持 webpack 兼容的前提下实现 10 倍性能提升。从 1.0 到 2.0 发布的近两年间做到了什么周下载量从 10 万增长到500 万——50 倍增长陆续引入增量构建、按需编译、持久化缓存、常量折叠Constant Folding、桶文件Barrel 文件即 index 统一导出文件优化等特性围绕 Rspack 打造了完整工具链 RstackRsbuild、Rslib、Rstest、Rspress、Rsdoctor、Rslint社区支持Angular、Nuxt、Next.js、Storybook、Docusaurus、Modern.js 等框架已提供 Rspack 适配2.3 为什么要搞 2.0Rspack 团队自己说得很直白“Rspack 的目标不只是成为一个「更快的 webpack」。在 1.x 阶段我们有意让 Rspack 的 API 和默认值与 webpack 5 保持一致这是为了帮助现有项目低成本迁移。但随着 JavaScript 模块规范和生态的发展一些历史设计已不再适合作为当下的默认选择。”1.x 是长得像 webpack来吸引你迁移2.0 开始做自己。2.0 的 ESM 化、RSC 支持、产物优化、配置简化——这些都不是 webpack 会做的事情。Rspack 在保持兼容的前提下开始引入更符合 2026 年 JavaScript 生态的默认行为。3. 怎么用上 Rspack 2.03.1 新项目直接用Rsbuild如果你是首次使用 Rspack推荐直接用 RsbuildRspack 驱动的开箱即用构建工具npmcreate rsbuildlatestRsbuild 2.0 已经跟 Rspack 2.0 同步发布开箱即用不需要折腾配置。3.2 从 Rspack 1.x 升级第一步升级依赖{devDependencies:{rspack/core:^2.0.0,rspack/cli:^2.0.0,rspack/dev-server:^2.0.0,rspack/plugin-react-refresh:^2.0.0}}第二步确认 Node.js 版本Rspack 2.0 要求 Node.js 20.19 或 22.12不再支持 Node.js 18。node-v# 如果低于 20.19先升级 Node.js第三步处理 Breaking Changes主要的破坏性变更变更影响解决方案移除module.unsafeCache缓存配置需调整用cache.type: persistent替代rspack/cli不再默认依赖rspack/dev-serverrspack serve命令需要手动安装 dev-servernpm add rspack/dev-server -Dresolve.exportsPresence默认值从warn改为error导出不存在时直接报错⚠️ 最容易导致 CI 构建失败的破坏性变更许多第三方库的exports字段书写不规范会被误杀。升级后如果构建失败可在resolve.exportsPresence设为warn降级为警告不中断构建builtin:swc-loader不再读.swcrcSWC 配置需迁移到 loader options把配置移到rspack.config.mjsoutput.chunkLoadingGlobal默认值变更chunk 全局变量名从webpackChunk变为rspackChunk如有依赖可显式配置webpack-bundler-analyzer被移除--analyze参数失效改用 Rsdoctoroutput.libraryTarget等配置迁移库构建配置语法变更迁移到output.library.typedevServer.hot默认值变更热更新默认不再自动开启需手动配置devServer.hot: true否则升级后 HMR 失效统计输出stats配置重构部分 webpack 兼容的 stats 字段被移除自定义日志输出需适配新格式resolve.exportsPresence降级示例exportdefaultdefineConfig({resolve:{exportsPresence:warn},});第四步可选用 Agent 辅助迁移如果你在用 Coding Agent比如 Cursor、Claude Code 等可以安装 Rspack 官方的迁移 Skillnpx skillsaddrstackjs/agent-skills--skillrspack-v2-upgrade装好后让 Agent 帮你完成升级通常比手动改更高效。3.3 从 webpack 迁移如果你还在用 webpackRspack 的迁移路径已经非常成熟了。核心步骤# 1. 安装 Rsbuild最简路径npmcreate rsbuildlatest# 2. 选择 Convert from webpack 模式# Rsbuild 会自动尝试转换你的 webpack.config.js或者手动迁移importpathfromnode:path;import{fileURLToPath}fromnode:url;import{defineConfig}fromrspack/core;// 2.0 推荐 ESM 配置文件不再默认有 __dirname需手动声明const__dirnamepath.dirname(fileURLToPath(import.meta.url));exportdefaultdefineConfig({entry:./src/index.js,output:{path:path.resolve(__dirname,./dist),// 必须使用绝对路径},module:{rules:[{test:/\.(?:js|mjs|jsx|ts|tsx)$/,use:{loader:builtin:swc-loader,options:{// 2.0 新特性自动推断语法替代手写 syntax jsx/tsx 布尔值detectSyntax:auto,jsc:{transform:{react:{runtime:automatic,},},},},},},],},});2.0 新增的detectSyntax: auto大幅简化了多文件类型的 loader 配置以前要写多条 rules 分别处理.js、.jsx、.ts、.tsx还要手动指定jsc.parser.syntax、jsx、tsx等选项现在一条规则全搞定根据文件扩展名自动推断该用哪种语法解析。注意output.path必须传绝对路径直接写相对路径在 ESM 配置文件下会报错。因为 2.0 推荐用 ESM 配置文件不再默认有__dirname需要通过fileURLToPath手动声明——这是很多用户升级会踩的坑。3.4 从 webpack 迁移要注意什么需要注意的是95% 兼容主要覆盖常用 API 与主流生态深度定制的项目迁移仍可能遇到兼容性问题。几个常见问题1. 自定义 webpack 插件如果你的项目有自己写的 webpack 插件需要检查是否用到了 Rspack 未实现的 API。大部分插件的 tapable hooks 都是兼容的但一些边缘 API 可能没覆盖。2. 特定 loader 兼容性大部分常用 loaderbabel-loader、css-loader、style-loader、postcss-loader都是兼容的。但一些小众 loader 可能有问题需要在 Plugin 兼容列表 里查一下。3. 模块联邦Rspack 支持模块联邦但module-federation/runtime-tools在 2.0 中变成了可选依赖。如果你用了模块联邦需要手动安装npmaddmodule-federation/runtime-tools4. 产物验证与灰度方案大型项目迁移最关心风险控制建议分阶段推进开发环境先切——先在开发环境切换到 Rspack验证 HMR、代理、静态资源等基础功能生产环境双构建对比——同时跑 webpack 和 Rspack 生产构建对比产物体积、sourcemap、核心功能回归逐步全量——确认无差异后逐步将 CI 流水线切换到 Rspack4. 该选谁维度Rspack 2.0ViteTurbopack底层语言RustRust (Rolldown 生产构建)Rustwebpack 兼容⭐⭐⭐⭐⭐ (常用 API ~95%)❌❌开发体验⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐ (仅 Next.js)大型项目构建⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐产物质量 / Tree Shaking⭐⭐⭐⭐⭐ (CJS ESM 均强)⭐⭐⭐⭐⭐ (纯 ESM 项目上限更高CJS 兼容项目弱于 Rspack)⭐⭐⭐⭐生态成熟度⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐RSC 支持✅ (实验性基础链路)✅ (通过框架)✅ (Next.js)适用场景webpack 迁移 / 大型项目中小型 SPANext.js 项目维护方字节跳动VoidZero (尤雨溪)Vercel并不是说 Rolldown 跑不动大项目它在底层性能上已经足够优秀。差异在于生态兼容性Vite 的产物构建走 Rollup/Rolldown 链路无法直接复用 webpack 的 loader 和插件。如果你的大型项目重度依赖 webpack 生态比如自定义 compiler hooks、特定的 webpack loaderRspack 是更平滑的选择。一个比较务实的选型原则新项目中小型 SPA→ Vite开发体验最好Rolldown 核心已经成熟webpack 存量项目→ Rspack迁移成本最低常用 API 95% 兼容Next.js 项目→ Turbopack原生集成Next.js 专属第一公民微前端 / 深度定制 webpack hooks→ RspackModuleFederation 和 compiler hooks 生态不可替代不确定 / 想留后路→ Rspack因为它的 webpack 兼容性给你最大的退路5. QAQ1: Rspack 和 webpack 的核心区别是什么核心区别是底层实现语言。webpack 用 JavaScript 编写受限于 Node.js 单线程模型和 V8 引擎的 GC 压力Rspack 用 Rust 编写核心利用 Rust 的内存安全、零成本抽象和多线程能力。性能方面无缓存首次构建约为 webpack 的 5-10 倍持久化缓存命中场景可达 20 倍以上。同时 Rspack 对 webpack 常用 API 与主流生态有约 95% 的兼容度大幅降低迁移成本。Q2: Rspack 2.0 转为纯 ESM 包对使用者有什么影响对大多数项目没有影响。Node.js 22.12 已稳定支持 CommonJS 中通过require()加载 ESM 模块20.19 为实验性支持。所以即使你的项目是 CommonJS 的在符合 Node 版本要求的前提下也能正常使用 Rspack 2.0。⚠️ 但有一个边界情况如果 ESM 模块内部使用了顶层 awaitTop-level awaitrequire()会直接抛出ERR_REQUIRE_ASYNC_MODULE错误无法绕过。目前 Rspack 2.0 核心包自身没有使用顶层 await但如果你在配置文件中引入的第三方 ESM 依赖含有顶层 awaitCJS 项目就会挂掉。解决方案把rspack.config.js改名为rspack.config.mjs或在package.json中设置type: module将项目切换为 ESM 模式。另外Rspack 2.0 不再支持 Node.js 18最低要求 20.19 或 22.12。Q3: 什么是#__NO_SIDE_EFFECTS__注解它解决了什么问题这是构建器注解Bundler Annotations规范中定义的注解用于将函数标记为无副作用。当被标记函数的调用返回值未被使用时tree shaking 可以安全移除该调用。这解决了一个长期问题跨模块的函数调用即使返回值没被使用因为函数体可能有副作用比如修改全局变量、发请求打包工具不敢删。有了这个注解打包工具就知道可以安全删除。Q4: Rspack 2.0 的依赖瘦身为什么重要两个原因。第一依赖越少安装越快磁盘占用越小——rspack/dev-server从 15MB 降到 1.4MB 是实打实的体感提升。第二依赖越少供应链风险越低。npm 生态中一个传递依赖被投毒或意外破坏的事件并不罕见。Rspack 通过把依赖打包进发布产物vendor 化、用 Node.js 原生 API 替代第三方包等方式大幅降低了这种风险。但要注意vendor 化意味着你无法通过npm overrides直接升级传递依赖版本来修复 CVE 漏洞需依赖官方发版patch-package虽可对打包后的产物生效但维护成本极高不推荐企业级项目使用。Q5: 在什么场景下应该选择 Rspack 而不是 Vite两个典型场景1有大量 webpack 存量代码——包括自定义 loader、插件、配置文件或重度依赖 webpack 特有的能力如模块联邦、特定的 compiler hooks迁移到 Vite 意味着重写整个构建链路成本远高于切换到 Rspack2微前端主应用——需要与多个基于 webpack 构建的子应用协同Rspack 的模块联邦生态兼容性是刚需。反之如果是从零开始的中小型 SPA不涉及 webpack 历史包袱Vite 的零配置开发体验依然是首选。参考资料Rspack 2.0 发布公告 - 官方博客Rspack 2.0 升级指南InfoQ: RSPack 2.0 性能提升、更精简的依赖项和 ESM 核心rspack-react-10k-benchmark以上就是本节的全部内容如果你觉得有收获欢迎关注持续分享好文下期见
