Rspack 1.0：Webpack 接班人現身

如果你曾經因為 Webpack 的建置速度而崩潰過——冷啟動 3 分鐘、修改一個檔案要等 10 秒——Rspack 1.0 可能就是你等待了很久的答案。Rspack 是一個用 Rust 開發的 bundler，它的設計目標是與 Webpack 完全相容，但效能提升 5-10 倍。2026 年 Rspack 1.0 正式 production-ready，越來越多企業開始遷移。這篇文章幫你評估：Rspack 是否適合你的專案？

Webpack 的歷史包袱

Webpack 2012 年發布，是那個年代的正確答案。當時 JavaScript 模組化剛剛起步，Webpack 的 code splitting、chunking、和豐富的 plugin 生態，解決了大型前端專案的建置需求。

但 2026 年的 Webpack 面臨一個根本問題：JavaScript 寫的 bundler，無法在現代大型專案的規模下保持快速。

Webpack 的建置時間隨著專案規模線性增長：
- 100 個模組：10 秒
- 1000 個模組：2 分鐘
- 5000+ 個模組：5-10 分鐘

這就是 Rspack 出現的背景：用 Rust 重新實現 Webpack 的功能，擺脫 JavaScript 的效能限制。

Rspack 1.0 的效能數據

基準測試

指標	Webpack	Rspack	提升
冷啟動	3 分鐘	10 秒	18x
熱更新（HMR）	10-30 秒	<1 秒	10-30x
Production 建置	8 分鐘	90 秒	5x
JavaScript 建置	基準	23x 快	23x

企業真實案例

Mews（酒店管理系統）的遷移結果：

# 遷移前（Webpack）
建置時間：3 分鐘
熱更新：15 秒

# 遷移後（Rspack）
建置時間：10 秒
熱更新：<1 秒

每週節省工程師等待時間：約 8 小時 / 團隊。

與 Webpack 的相容性

Rspack 最重要的設計決策：與 Webpack 生態系的相容性。

支援的 Webpack 功能

webpack.config.js 大部分配置可以直接使用
支援大多數 webpack plugins
支援 resolve.alias、resolve.extensions
支援 code splitting 和 chunking
支援 externals

遷移成本

專案規模	預估遷移時間
小型（< 100 modules）	半天
中型（100-1000 modules）	1-2 天
大型（1000-5000 modules）	1 週
超大型（> 5000 modules）	2-3 週

不支援的功能

少數 Webpack 功能 Rspack 尚未支援：

// 需要替換的 webpack 特定功能
// 1. webpack-dev-server → @rspack/dev-server
// 2. certain webpack plugins that use internal APIs

// rspack.config.js
export default {
  // 大部分 webpack 配置直接可用
  entry: './src/index.js',
  output: {
    filename: '[name].js',
  },
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: 'babel-loader',  // 大多數 loader 直接可用
      },
    ],
  },
  // Rspack 特定的優化選項
  optimization: {
    // Rspack 的 code splitting 略有不同
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          chunks: 'all',
        },
      },
    },
  },
};

與 Vite 的比較

Vite 的定位

Vite 使用 esbuild（開發）+ Rollup（生產），是一個非常好的開發體驗選擇。但 Vite 的生產建置效能不如 Rspack。

Rspack vs Vite

維度	Rspack	Vite
開發建置	快（esbuild/Rust）	非常快（原生 ESM）
生產建置	極快（Rust）	快（Rollup）
Webpack 相容性	✅ 完全相容	❌ 需要適配
Plugin 生態	Webpack 生態	Vite/Rollup 生態
生態成熟度	成長中	成熟
適合場景	大型企業遷移	新專案、中小型專案

Rsbuild：Rspack 的上層封裝

ByteDance 還開發了 Rsbuild——一個更易用的建置工具，封裝了 Rspack 並提供與 Vite 相近的 API：

// rsbuild.config.js
import { defineConfig } from '@rsbuild/core';

export default defineConfig({
  source: {
    entry: './src/index.js',
  },
  output: {
    distPath: './dist',
  },
  tools: {
    // 與 Vite 相近的配置方式
    postcss: {},
    sass: {},
  },
});

Rslib：元件庫建置

對於需要建置和發布元件庫的團隊，Rslib 是另一個值得关注的工具：

# Rslib 使用 Rspack 作為底層
npm install @rslib/core -D

// rslib.config.js
import { defineConfig } from '@rslib/core';

export default defineConfig({
  output: {
    packageFields: {
      // 自動生成 CJS + ESM 輸出
    },
  },
});

Rslib 的目標是：讓元件庫建置像 Vite 一樣簡單，但享有 Rspack 的效能。

企業採用情況

已遷移的企業案例

Mews：酒店管理系統，建置時間從 3 分鐘降到 10 秒
多個 ByteDance 內部專案：大規模遷移驗證
電商平台：大型前端專案遷移

生態成熟度

# 每週下載量 ~80 萬
# GitHub stars 持續成長
# 主流框架支援：Next.js、Vue CLI、Storybook

Next.js 整合

Next.js 正在實驗 Rspack 作為替代的 bundler：

// next.config.js
module.exports = {
  // 實驗性支援 Rspack
  experimental: {
    rspackBundler: true,
  },
};

何時該考慮遷移到 Rspack

適合遷移的場景

建置時間成為開發瓶頸：每次修改等 30 秒以上
大型 Webpack 專案：遷移成本可控
需要更好的 CI/CD 效能：建置時間影響部署頻率
團隊對 Webpack 熟悉：不想學習全新的工具

不適合遷移的場景

新專案：直接用 Vite 或 Rsbuild
已經是 Vite：Rspack 在開發體驗上沒有優勢
高度客製化的 Webpack 配置：某些 plugin 可能不相容

結語：Webpack 的時代結束了嗎

Rspack 1.0 的出現，不意味著 Webpack 會立刻消失。Webpack 的生態系仍然龐大，許多企業有數年累積的 Webpack 配置和 plugin。

但 Rspack 的出現代表了一個明確的方向：企業級前端專案的建置，正在從 JavaScript 轉向 Rust。就像當年 Grunt 被 Gulp取代、Gulp 被 Webpack 取代、Webpack 面臨 Rolldown 和 esbuild 的挑戰一樣，建置工具的效能最佳化是不變的主題。

如果你現在正在維護一個大型 Webpack 專案，Rspack 1.0 值得你認真評估。80% 的建置時間減少，對於開發體驗的提升是巨大的。