Rspack 2.3 与 SWC 团队协作：迁移前核验 5 项

“换了编译器，构建就一定更快”——这个判断并不成立。Rspack 2.3 与 SWC 团队协同推出新编译器，但这次发布首先意味着编译链路发生变化，不能据此预设构建提速幅度。 现有资料可以确认这次协作发布，却不足以证明 Rspack 2.3 的具体性能增幅，因此不宜把其他版本或单个项目的数据当作 Rspack 2.3 的官方性能成绩。

性能评估至少应区分三层：编译器单项吞吐、Rspack 端到端构建耗时，以及页面运行效果。只有第一层能直接归因于编译器变化。对已有 Rspack + SWC 项目，通常不需要整套重写配置，应先核对编译器入口、版本和选项差异；对 Webpack 5 + Babel 项目，则应先建立配置映射，再移除旧链路，不能看到 SWC 更快就直接删掉 Babel。

迁移前应先核对新旧编译器的职责边界。下表是一份保守的迁移核验表，按环节列出核验范围；它不代表 Rspack 2.3 会自动替换所有环节，精确的默认行为和启用方式仍应以对应版本说明为准。

Rspack 内置的 builtin:swc-loader 与独立安装的 swc-loader 是两个需要区分的入口，不应在同一条规则中混用。已有项目可以先用下面的命令确认实际安装版本，再对照 lockfile 和 2.3 的版本说明：

npm ls @rspack/core swc-loader @swc/core

Webpack 5 + Babel 项目可以从类似的配置映射开始，但这只是检查配置结构，不是“替换后天然等价”的证明：

module: {
  rules: [
    {
      test: /\.(?:js|jsx|mjs|ts|tsx)$/,
      exclude: /node_modules/,
      loader: 'builtin:swc-loader',
      options: {
        detectSyntax: 'auto',
        jsc: {
          target: 'es2022',
          transform: {
            react: {
              runtime: 'automatic'
            }
          }
        },
        env: {
          targets: '> 0.5%, last 2 versions'
        }
      }
    }
  ]
}

jsc.target、env.targets 和 JSX runtime 都需要按项目现状设置，而不是照抄示例。TypeScript 编译与类型检查也应分开，SWC 负责转译不代表它会替代类型检查：

npx tsc --noEmit

装饰器，尤其是依赖注入框架使用的 legacy 语义、类型元数据和副作用顺序，不能仅凭“能够解析”就判定兼容。自定义 Babel 插件同样应先建立逐项映射，在替代实现通过测试前不应删除原有插件；SWC Wasm 插件目前宜作为实验能力单独评估。

迁移故障往往不是由语法转换引起，而是出在外围配置。迁移时需要为插件寻找 Rspack 兼容版本，例如评估以 html-rspack-plugin 替代 html-webpack-plugin。环境变量注入要检查 DefinePlugin 到 rspack.define 的映射。file-loader、动态 import() 与代码分割、Sass/Less 参数、@rspack/plugin-legacy、experimental.runtimeModule 以及开发服务器配置，也都应逐项处理。 每改完一组配置就执行一次构建和运行时冒烟测试，比一次性替换全部链路更容易定位问题。

判断是否更快，需要先固定测试口径。资料中的 React 中台案例包含 200 多个组件和 15 个以上路由页面：迁移前基于 Webpack 5，冷启动为 68 秒，HMR 平均 1.2 秒；迁移后编译阶段内存占用降低 40%，主包从 1.2MB 降至 980KB，FCP 从 2.1 秒降至 1.4 秒。 这仍然只是一个历史项目案例。资料没有给出迁移后的冷构建和 HMR 数值，也没有把该案例标注为 Rspack 2.3 官方测试，因此不能据此计算 2.3 的提速倍数。

项目自身的对比测试至少应固定机器、CPU、内存、Node 版本、依赖锁文件和环境变量，并分别记录冷构建、热构建、HMR 延迟、进程峰值内存、产物体积和 FCP。冷构建与热构建必须分开统计，峰值内存应覆盖主进程和 worker，产物比较也不能只看总大小，还要核对 chunk、动态导入和资源文件是否发生变化。

已有 Rspack 项目适合按照“构建核心、Rspack 优化、外围生态”三个阶段推进：先确认新编译器与现有 SWC 配置等价，再验证内置优化，最后迁移 CI、部署脚本和周边插件。 可以先建立灰度分支，在 CI 中比较构建产物、HMR 和核心页面，再逐步扩大范围。新项目则应从默认配置和锁定版本开始；自定义 Babel 插件较多的项目，不宜为了尝鲜而复制一套复杂的旧配置。

上线前可按以下五项核验：

1. 确认编译器入口与启用方式：记录 Rspack 2.3 对应的启用项、默认值和 @rspack/core、loader、@swc/core 版本，避免两套入口混用。
2. 确认语法与浏览器目标：覆盖 TypeScript、JSX runtime、装饰器、source map、jsc.target、Browserslist 和旧浏览器产物。
3. 确认 Babel 及插件映射：每个自定义 Babel 插件都应有替代方案、测试样例或明确的保留理由。
4. 确认性能验收阈值：根据项目基线设置冷构建、热构建、HMR、峰值内存、产物体积和页面指标的通过线，不用一次测量代替稳定结果。
5. 确认发布与回滚方案：完成灰度构建、产物对比和运行时冒烟测试，并准备可恢复的 lockfile、配置和工具链版本。

Rspack 2.3 可以进入迁移评估，但应先验证新编译器能否在项目代码和插件链中保持原有行为，再依据固定口径的测试结果判断性能收益。