你有沒有經歷過這樣的“地獄時刻”？

凌晨兩點，線上發布在即，你按下 npm run build，然后……盯著終端發呆，看著打包進度條一毫米一毫米地爬行。 然后剛打包好發布上去之后，還有點沒改到...崩潰20 分鐘。

對于一個日活百萬的中后臺系統，這不僅是等待，更是成本、焦慮和機會的流失。

而我們團隊，剛剛完成了一次“不可能的任務”：將一個維護了 8 年、超過 120 萬行代碼、依賴龐雜的“祖傳項目”，從 Webpack 4 遷移到 Rspack，打包時間從 20.3 分鐘 → 4.8 分鐘，提升近 4 倍！

本文將復盤這次遷移的完整路徑、踩坑記錄和真實收益，希望能為同樣被“慢打包”折磨的你，提供一份實戰參考。

一、項目背景：一個典型的“技術債”重災區

我們的項目是一個大型企業級中后臺系統，具備以下特征：

• 代碼量：120萬+ 行（含 node_modules）
• 技術棧：Vue 2 + Webpack 4 + Babel + ESLint + 多個自研 UI 庫
• 構建痛點：

開發環境 npm run serve 冷啟動 3.5 分鐘

生產環境 npm run build 平均耗時 20.3 分鐘

HMR（熱更新）緩慢，修改后需等待 15-30 秒

團隊規模 30+ 人，每天平均構建 200+ 次，年累計等待時間超 2000 小時

我們嘗試過各種 Webpack 優化：

• webpack-bundle-analyzer 拆包
• cache-loader / hard-source-webpack-plugin
• thread-loader
• splitChunks 優化

但收益有限，打包速度始終卡在 18-22 分鐘之間。

直到我們決定：換構建工具。

二、為什么選擇 Rspack？而不是 Vite 或 Turbopack？

我們評估了當前主流的下一代構建工具：

關鍵決策點：

• Rspack 提供了 @rspack/cli 和 @rspack/core，90% 的 Webpack 配置可直接復用
• 官方提供 webpack.config.js 到 rspack.config.js 的平滑遷移指南
• 背靠字節跳動，已在多個大型項目驗證

三、遷移實戰：五步走策略

我們采用“漸進式遷移 + 并行驗證”策略，避免“一次性大爆炸”風險。

? 第一步：環境準備與兼容性驗證

• 安裝 Rspack：

npm install @rspack/cli @rspack/core -D

• 創建 rspack.config.js，復用原有 webpack.config.js 結構：

const { RspackOptions } = require('@rspack/core');
const config = require('./webpack.config.js'); // 復用原配置


module.exports = {
  ...config,
  // Rspack 特有優化
  experiments: {
    css: true
  },
  module: {
    rules: config.module.rules.map(rule => {
      // 替換 Webpack 特有 loader
      if (rule.loader?.includes('css-loader')) {
        return { ...rule, loader: '@rspack/loader-css' };
      }
      return rule;
    })
  }
};

• 運行測試構建：

npx rspack build

結果：首次構建失敗，報錯 Module not found: css-loader —— Rspack 使用自己的 loader。

? 第二步：Loader 與 Plugin 適配

Rspack 不完全兼容 Webpack 的 loader，需替換：

我們編寫了自動化腳本，批量替換配置中的 loader 名稱，并測試構建。

? 第三步：性能調優配置

在 Rspack 基礎上，我們啟用以下優化：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
module.exports = {
  // 1. 啟用多進程構建
  optimization: {
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          chunks: 'all'
        }
      }
    }
  },
  // 2. 啟用持久化緩存
  snapshot: {
    managedPaths: [path.resolve(__dirname, 'node_modules')],
    immutablePaths: [path.resolve(__dirname, 'dist')]
  },
  // 3. 啟用 CSS 支持
  experiments: {
    css: true
  },
  // 4. 啟用解析緩存
  resolve: {
    alias: config.resolve.alias,
    extensions: ['.js', '.vue', '.json']
  }
}

? 第四步：CI/CD 流程切換

在 Jenkins 流水線中，將 webpack build 替換為：

ounter(lineounter(lineounter(lineounter(lineounter(line
# 使用 Rspack 構建
npx rspack build --config rspack.config.js


# 保留 Webpack 作為 fallback
# npm run build:webpack

并添加構建時間監控，實時對比 Rspack 與 Webpack 的性能差異。

? 第五步：全量上線與監控

• 先在測試環境驗證 1 周，確保構建產物一致
• 灰度發布 30% 發布任務使用 Rspack
• 監控 CDN 資源加載、頁面功能、錯誤率
• 確認無異常后，全量切換

四、成果對比：性能提升一覽

?? 經濟效益：按團隊 30 人、每人每天構建 7 次計算，年節省開發等待時間約 1800 小時，相當于節省 1 名全職工程師的工時。

五、踩坑總結：你可能遇到的問題

1.CSS Modules 不兼容：Rspack 默認不支持 CSS Modules，需顯式配置：

experiments: {
  css: true
},
module: {
  rules: [
    {
      test: /\.module\.css$/,
      use: [
        '@rspack/loader-style',
        {
          loader: '@rspack/loader-css',
          options: {
            modules: true
          }
        }
      ]
    }
  ]
}

2.自定義 Plugin 不兼容：部分 Webpack Plugin 無法直接運行，需尋找替代或改用 Rspack 插件。

3.Source Map 生成較慢：生產環境建議使用 source-map 而非 inline-source-map。

4.Node.js 版本要求：Rspack 要求 Node.js 16+，需升級運行環境。

六、寫在最后：不是所有項目都適合，但值得一試

Rspack 并非銀彈。對于小型項目，Webpack 依然夠用。但對于中大型、長期維護、對構建效率敏感的項目，Rspack 是一個極具性價比的升級選擇。

它讓我們意識到：構建工具的性能，本質上是開發體驗和團隊效率的基礎設施。

替換需謹慎，踩坑可能多！