万字深度解析 Rspack：当字节跳动用 Rust 重写前端构建——从三明治架构到 5-10 倍性能提升的完整技术指南（2026）

一、背景：为什么字节跳动要自研一个构建工具？

如果你在前端圈子里待得够久，一定经历过这种场景：打开一个中大型前端项目，光是等待 npm install 跑完就要几分钟，敲下 npm run dev 之后盯着终端发呆，看着进度条一点一点爬——两分钟、三分钟、五分钟。终于启动了，改一行 CSS，热更新愣是等了十几秒才生效。做一次生产构建，喝完一杯咖啡还没完。

这并不是个例。根据字节跳动工程师在内部实践分享中的描述，公司的巨型应用冷启动时间普遍在 2-5 分钟，生产构建时间更是高达 15-30 分钟。团队不是没有尝试过社区方案——确实有 esbuild-loader、swc-loader、HardSourceWebpackPlugin 等一系列性能优化手段，但这些方案的切入点比较单一，没有从根本上解决 Webpack 基于 JavaScript/Node.js 的架构瓶颈。

Rspack 的诞生，就是在这个背景下的一次"掀桌子"。

字节跳动的工程师们没有选择继续在 Webpack 生态里打补丁，而是做了一个大胆的决定：用 Rust 重写整个构建引擎，同时保持对 Webpack 配置格式和生态插件的兼容性。这样既能在性能上获得数量级的提升，又不需要让团队从零开始重建生态。

这个思路和 Bun（Neyser 的 Zig → Rust 重写 JavaScript 运行时）、Turbo/Rsbuild（Vercel 的 Turbopack）代表了 2026 年前端基础设施领域最重要的一个趋势：用 Rust/Go 这类系统级语言重写 Node.js 的核心瓶颈模块，以获得 5-100 倍的性能提升。

二、Rspack 是什么？

Rspack 是字节跳动 Web Infra 团队开源的高性能 Web 构建工具，基于 Rust 语言开发，兼容 Webpack 的配置 API 和生态。它的核心定位是：提供与 Webpack 完全兼容的 API，但在构建性能上达到 5-10 倍的提升。

从 GitHub 数据来看，截至 2026 年 6 月，Rspack 仓库已有 40,000+ Stars、8898 次提交，是前端基础设施领域最活跃的 Rust 项目之一。其生态已经从单一的构建工具扩展到了 Rsbuild（上层脚手架）、rspack-sources（Rust 版 webpack-sources）、module-federation（模块联邦）等多个方向。

2.1 与 Vite、Turbopack 的区别

很多人会拿 Rspack 和 Vite、Turbopack 做对比。三者确实都在解决同一个问题——Webpack 太慢——但路径不同：

Rspack 的核心优势在于不需要重构团队已有的 Webpack 配置和插件体系，可以直接替换底层引擎，实现渐进式迁移。

三、架构设计：三明治结构的跨语言工程

Rspack 架构最精妙的地方在于它的三层架构设计——Node.js 用户接口层、Node-API 胶水层、Rust 核心编译层。这套"三明治"结构让它既享有 Rust 的极致性能，又保持了完整的 JavaScript 生态接入能力。

┌─────────────────────────────────────────────────────────────┐
│                     Node.js 用户层                          │
│  rspack CLI / rspack.config.js / JavaScript API / Loader   │
└──────────────────────────┬────────────────────────────────┘
                           │ Node-API (napi-rs)
┌──────────────────────────▼────────────────────────────────┐
│                     Binding 胶水层                          │
│  rspack_binding_api: Rust → JS 类型转换 / 内存管理 / 回调   │
│  #[napi] 宏生成 JS 兼容接口                                 │
└──────────────────────────┬────────────────────────────────┘
                           │ Rust FFI
┌──────────────────────────▼────────────────────────────────┐
│                    Rust Core 编译引擎                        │
│  rspack_core: Compiler / Compilation / Plugin / Loader    │
│  rspack_fs: 文件系统抽象                                    │
│  rspack_resolver: 依赖解析                                   │
│  rspack_loader: Loader 调度                                  │
└─────────────────────────────────────────────────────────────┘

3.1 Node.js 用户层：生态的桥梁

Node.js 层的职责有三个：

用户交互与配置解析。Rspack 完全兼容 Webpack 的配置格式，这意味着你现有的 webpack.config.js 或 webpack.config.ts 在大多数情况下可以直接在 Rspack 中使用。配置通过 Node.js 层解析后，序列化为 JSON，传递给 Rust 核心层。

// webpack.config.js → 几乎可以直接迁移到 rspack.config.js
module.exports = {
  entry: './src/index.tsx',
  output: {
    filename: '[name].[contenthash].js',
    path: __dirname + '/dist',
  },
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: 'babel-loader', // Webpack 生态的 loader 直接可用
        exclude: /node_modules/,
      },
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader'],
      },
    ],
  },
  plugins: [
    new HtmlWebpackPlugin({ template: './src/index.html' }),
    new DefinePlugin({ 'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV) }),
  ],
  optimization: {
    splitChunks: { chunks: 'all' },
    runtimeChunk: 'single',
  },
  devServer: {
    port: 3000,
    hot: true,
  },
};

Loader 调度。Rspack 保留了 Webpack 的 Loader 机制，JavaScript 写的 Loader 仍然能正常工作。这是因为 Loader 的执行由 Node.js 层负责调度，Rust 层只需要接收处理后的结果：

// 自定义 Rspack Loader（JavaScript）
// loader/my-custom-loader.js
module.exports = function(source, sourceMap) {
  // 在 Loader 阶段可以对源码做预处理
  const processed = source.replace(/__VERSION__/g, process.env.npm_package_version);
  // 返回处理后的内容（传递给下一个 Loader 或 Rspack 核心）
  return processed;
};

// rspack.config.js
module.exports = {
  module: {
    rules: [
      {
        test: /\.special$/,
        loader: './loader/my-custom-loader.js',
      },
    ],
  },
};

JavaScript API。Rspack 提供了完整的 JavaScript SDK，允许在 Node.js 代码中以编程方式调用构建：

const rspack = require('@rspack/core');
const rspackConfig = require('./rspack.config.js');

async function build() {
  const compiler = rspack.createCompiler({
    options: rspackConfig,
  });

  compiler.run((err, stats) => {
    if (err) {
      console.error('Build failed:', err);
      return;
    }
    console.log(stats.toJson({
      assets: true,
      chunks: true,
      modules: false,
    }));
  });
}

build();

3.2 Binding 胶水层：napi-rs 的精妙运用

Binding 层使用 Facebook 开源的 napi-rs 框架，实现了 Rust 和 Node.js 之间的高效双向通信。这是整个架构中最"魔法"的部分——开发者写 Rust 代码只需要加上 #[napi] 宏，就能自动生成兼容 Node.js 的 API：

// rspack_binding_api/src/lib.rs（简化示例）
use napi::{bindgen_prelude::*, JsObject};
use rspack_core::{Compiler, RspackOptions};

#[napi]
pub struct JsCompiler {
  inner: Compiler,
}

#[napi]
impl JsCompiler {
  #[napi(constructor)]
  pub fn new(options: JsObject) -> Result<Self> {
    // 将 JS 配置对象转换为 Rust 内部配置
    let rspack_options: RspackOptions = parse_options(options)?;
    let compiler = Compiler::new(rspack_options);
    Ok(Self { inner: compiler })
  }

  #[napi]
  pub fn build(&self, env: Env) -> Result<JsObject> {
    // 调用 Rust 编译逻辑，返回 JS 兼容的结果对象
    let result = self.inner.build()?;
    // 内存管理和类型转换由 napi-rs 自动处理
    env.to_js_value(&result)
  }

  #[napi]
  pub fn watch(&self, options: WatchOptions, env: Env) -> Result<JsWatchResult> {
    // 监听文件系统变化，触发增量构建
    // ...
  }
}

napi-rs 解决了几个关键问题：

• 内存管理：Node.js 和 Rust 的 GC 边界处理，通过 #[napi] 宏自动生成跨语言引用计数逻辑
• 类型转换：JavaScript 的动态类型和 Rust 的静态类型之间的自动映射
• 异步回调：Rust 的多线程执行结果通过回调安全地传回 JavaScript 事件循环

3.3 Rust Core：高性能的来源

Rust 核心层实现了构建工具的所有核心逻辑：

Compiler（编译器主控）：rspack_core::Compiler 管理整个构建生命周期——初始化配置、构建编译图、触发各个阶段的 Hook、执行插件、输出产物。这是整个系统的调度中心。

Compilation（编译过程）：Compilation 维护了从入口模块开始的所有模块、chunk、生成代码的完整有向图。每一次构建（增量或全量）都会产生一个新的 Compilation 实例。

Module（模块抽象）：Rspack 定义了抽象的 Module trait，支持多种模块类型：NormalModule（普通 JS/TS 模块）、CssModule、RawModule、RemoteModule（Module Federation）等。

Resolver（依赖解析）：Rspack 使用 Rust 实现的 rspack_resolver 来解析模块路径，比 Node.js 的 resolve 包快 10 倍以上。解析过程包括：

// 依赖解析的核心流程（简化）
pub fn resolve(module_request: &str, context: &Path) -> Resolution {
    // 1. 路径规范化（相对路径 / 绝对路径 / 包名）
    // 2. 文件系统查找（node_modules 查找规则）
    // 3. 扩展名补全（.ts → .tsx → .d.ts → index.ts）
    // 4. package.json main/exports 字段解析
    // 5. 缓存结果（同一路径只解析一次）
}

Plugin System（插件系统）：Rspack 实现了 Webpack 兼容的 Hook 体系。插件可以在以下阶段注入自定义逻辑：

// Rspack Plugin Hook 示例（Rust 实现）
pub struct MyCustomPlugin;

impl rspack_core::Plugin for MyCustomPlugin {
    fn apply(&self, ctx: &mut rspack_core::PluginContext, hook: &mut rspack_core::RegisterJsTaps) {
        // 在 compilation hook 中注册 Rust 端的处理逻辑
        hook.compilation.tap(compilation_hook(|compilation, _| {
            // Rust 并发处理，性能远高于 JavaScript 插件
            process_modules(&compilation.modules);
        }));
    }
}

四、核心技术原理

4.1 SWC 驱动的代码转译

Rspack 使用 SWC（Speedy Web Compiler）作为代码解析和转译的引擎。SWC 由 Vercel 开发，是用 Rust 编写的 TypeScript/JavaScript 编译器，性能比 Babel 快 20-100 倍。

Rspack 在 SWC 之上做了两件事：

第一，直接集成 SWC 的解析器。SWC 的核心是 swc_common、swc_ecma_parser 和 swc_ecma_transforms 三个 crate，Rspack 直接调用这些库进行 AST（抽象语法树）解析：

// SWC 解析流程
use swc_ecma_parser::{Parser, StringInput, Syntax, TsSyntax};
use swc_ecma_ast::*;

fn parse_typescript(source: &str) -> Module {
    let syntax = Syntax::Typescript(TsSyntax {
        tsx: true,
        ..Default::default()
    });
    let mut parser = Parser::new(syntax, StringInput::new(source, 0, 0), None);
    parser.parse_module().expect("Parse error")
}

// 解析后，Rspack 遍历 AST 进行依赖收集
fn collect_dependencies(module: &Module) -> Vec<Dependency> {
    // SWC 的 visitor 模式 —— 遍历 AST 节点
    // import / export / require() → 收集为 Rspack 的 Dependency
}

第二，内置 SWC 的转换器。Babel 需要的那些转译工作——TS → JS、JSX → JS、ESNext → ES5——SWC 都能做，而且是在 Rust 里并行完成的：

// SWC 配置在 Rspack 中的写法
// rspack.config.js
module.exports = {
  module: {
    rules: [
      {
        test: /\.tsx$/,
        use: {
          loader: 'builtin:swc-loader', // Rspack 内置的 SWC loader
          options: {
            jsc: {
              parser: {
                syntax: 'typescript',
                tsx: true,
              },
              transform: {
                react: {
                  runtime: 'automatic',
                  development: process.env.NODE_ENV !== 'production',
                },
              },
              target: 'es2015',
            },
          },
        },
      },
    ],
  },
};

关键点在于：builtin:swc-loader 是 Rust 内置的，不需要单独安装 swc-loader 包，Rspack 在初始化时直接实例化 Rust 层的 SWC 处理器。这消除了 Node.js ↔ Native 之间的 FFI 开销，解析和转译全部在 Rust 内部完成。

4.2 并行构建与增量编译

传统的 Webpack 构建是串行的——每个模块必须等待前一个模块解析完成后才能开始。Rspack 利用 Rust 的 rayon 并行计算库，将模块处理变成了并行流水线：

// Rspack 的并行模块处理（核心思路）
use rayon::prelude::*;

pub fn build_modules(compilation: &mut Compilation) {
    // 第一步：所有模块的依赖解析，全部并行
    let module_ids: Vec<ModuleId> = compilation.modules.keys().cloned().collect();
    let resolved: Vec<(ModuleId, Resolution)> = module_ids
        .par_iter()
        .map(|id| {
            let module = &compilation.modules[id];
            let deps = resolve_dependencies(module, &compilation.options);
            (id.clone(), deps)
        })
        .collect();

    // 第二步：所有已解析模块的代码生成，全部并行
    let code_gens: Vec<CodeGenResult> = resolved
        .par_iter()
        .map(|(id, deps)| {
            generate_code(&compilation.modules[id], deps, &compilation.options)
        })
        .collect();
}

增量编译（Incremental Compilation）是 Rspack 的另一个杀手级特性。当 HMR（热模块替换）触发时，Rspack 不会重建整个模块图，而是：

1. 记录构建指纹：每个模块的内容哈希 + 依赖关系哈希
2. 变化检测：只重新处理受影响的模块及其下游依赖
3. 产物复用：未受影响的 chunk 直接复用上次构建的结果

// Rspack Watch 模式的增量构建演示
const rspack = require('@rspack/core');

const compiler = rspack.createCompiler({
  entry: './src/index.tsx',
  mode: 'development',
  devtool: false,
  // 开启持久化缓存，构建产物会写入 node_modules/.cache/rspack/
  cache: true,
});

compiler.watch(
  { aggregateTimeout: 300, poll: undefined },
  (err, stats) => {
    // 第一次：完整构建
    // 后续：只构建变化的模块 + 受影响的下游模块
    console.log('Build time:', stats.endTime - stats.startTime, 'ms');
    console.log(stats.toJson({ modules: false }).modules);
  }
);

在字节跳动的实际业务中，开启增量构建后，HMR 耗时从 10-15 秒降低到 500 毫秒以内。

4.3 Tree Shaking 与代码分割的 Rust 实现

Webpack 的 Tree Shaking 基于 ES Module 的静态分析，但实现是 JavaScript 的，在大型项目中性能很差。Rspack 将这部分逻辑移植到 Rust：

// Tree Shaking 的核心算法（伪代码）
pub fn tree_shake(module_graph: &ModuleGraph) -> UnusedExports {
    // 1. 构建完整的 export → import 依赖图
    let export_graph = build_export_graph(module_graph);

    // 2. 从入口模块出发，标记所有被引用的导出
    let mut used_exports = HashSet::new();
    for entry_module in entry_modules {
        trace_exports(entry_module, &export_graph, &mut used_exports);
    }

    // 3. 收集所有未被使用的导出
    let unused: Vec<Export> = export_graph.all_exports
        .difference(&used_exports)
        .cloned()
        .collect();

    // 4. 生成"副作用"分析报告，指导最终的 Tree Shaking 决策
    unused
}

代码分割（Code Splitting）同样由 Rust 处理：

// rspack.config.js — splitChunks 配置与 Webpack 完全一致
module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'all',
      minSize: 20000,
      maxSize: 244000,
      cacheGroups: {
        // 将 node_modules 中的大包单独打包
        defaultVendors: {
          test: /[\\/]node_modules[\\/]/,
          priority: -10,
          reuseExistingChunk: true,
          name: 'vendors',
        },
        // 公共模块单独打包
        common: {
          minChunks: 2,
          priority: -20,
          reuseExistingChunk: true,
        },
        // React 生态单独打包
        react: {
          test: /[\\/]node_modules[\\/](react|react-dom|react-router)[\\/]/,
          name: 'react-vendor',
          chunks: 'all',
          priority: 10,
        },
      },
    },
    runtimeChunk: 'single',
  },
};

五、实战：从 Webpack 迁移到 Rspack

5.1 零配置迁移（React 项目）

对于大多数使用 Create React App 或手动配置 Webpack 的 React 项目，迁移到 Rspack 只需要两步：

步骤一：安装依赖

# 替换 webpack-cli 和 webpack-dev-server
npm uninstall webpack webpack-cli webpack-dev-server
npm install @rspack/core @rspack/cli --save-dev

# 如果使用了 webpack 特有插件，需要单独安装对应的 Rspack 版本
npm install @rspack/plugin-html @rspack/plugin-react-refresh --save-dev

步骤二：修改配置文件

// rspack.config.js
const path = require('path');
const HtmlRspackPlugin = require('@rspack/plugin-html');
const RefreshRspackPlugin = require('@rspack/plugin-react-refresh');

const isDev = process.env.NODE_ENV === 'development';

module.exports = {
  entry: {
    main: './src/index.tsx',
  },
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: isDev ? '[name].js' : '[name].[contenthash:8].js',
    chunkFilename: '[name].[contenthash:8].chunk.js',
    clean: true,
  },
  resolve: {
    extensions: ['.ts', '.tsx', '.js', '.jsx', '.json'],
    alias: {
      '@': path.resolve(__dirname, 'src'),
    },
  },
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        exclude: /node_modules/,
        use: {
          // Rspack 内置 SWC，零配置处理 TS/TSX
          loader: 'builtin:swc-loader',
          options: {
            jsc: {
              parser: {
                syntax: 'typescript',
                tsx: true,
              },
              transform: {
                react: {
                  runtime: 'automatic',
                  dev: isDev,
                },
              },
            },
          },
        },
      },
      {
        test: /\.css$/,
        use: isDev
          ? ['style-loader', 'css-loader']
          : ['@rspack/plugin-mini-css-extract', 'css-loader'],
      },
      {
        test: /\.(png|jpg|gif|svg|woff|woff2|eot|ttf|otf)$/,
        type: 'asset/resource',
      },
    ],
  },
  plugins: [
    new HtmlRspackPlugin({
      template: './public/index.html',
      favicon: './public/favicon.ico',
    }),
    isDev && new RefreshRspackPlugin(),
  ].filter(Boolean),
  devServer: {
    port: 3000,
    hot: true,
    historyApiFallback: true,
    client: {
      overlay: {
        errors: true,
        warnings: false,
      },
    },
  },
  optimization: {
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        default: false,
        vendors: false,
      },
    },
  },
  // Rspack 特有：持久化缓存，显著加速增量构建
  cache: true,
  context: __dirname,
};

package.json scripts：

{
  "scripts": {
    "dev": "rspack serve",
    "build": "rspack build",
    "build:analyze": "rspack build --analyze",
    "check": "rspack build --tsc"
  }
}

5.2 Rsbuild：开箱即用的上层脚手架

对于不想手动配置 Rspack 的团队，字节跳动官方提供了 Rsbuild——一个基于 Rspack 的上层脚手架，提供了开箱即用的开发体验。

Rsbuild 的核心理念是：提供一个精心预设的构建配置，开箱即用地支持主流前端框架，同时仍然可以通过插件 API 灵活扩展：

// rsbuild.config.ts — 比 Rspack 更简洁的配置
import { defineConfig } from '@rsbuild/core';
import { pluginReact } from '@rsbuild/plugin-react';
import { pluginSvgr } from '@rsbuild/plugin-svgr';

export default defineConfig({
  plugins: [
    pluginReact({
      // React 特有的 SWC 配置
      splitChunks: {
        strategy: 'vendor',
      },
    }),
    pluginSvgr(),
  ],
  source: {
    // 源码目录别名
    alias: {
      '@': './src',
    },
  },
  html: {
    template: './src/index.html',
  },
  performance: {
    // bundle 分析
    bundleAnalyze: {},
    // 预取优化
    preload: true,
  },
  tools: {
    // 暴露 Rspack 的底层配置
    rspack: (config, { appendPlugins }) => {
      appendPlugins([
        // 添加额外的 Rspack 插件
      ]);
    },
  },
});

Rsbuild 官方 benchmark 数据：构建 1000 个 React 组件，耗时 8.5 秒（对比 Webpack 同等规模需要 60+ 秒）。

5.3 与现有 CI/CD 集成

Rspack 完全兼容 Webpack 的配置格式，直接替换构建脚本即可：

# .github/workflows/build.yml
name: Build

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - name: Build with Rspack
        run: npx rspack build --mode production
        env:
          NODE_ENV: production
      - name: Upload artifacts
        uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/

六、性能优化：让 Rspack 跑得更快

即使 Rspack 本身就很快，以下几种方式可以进一步榨取性能：

6.1 持久化缓存

// rspack.config.js
module.exports = {
  // 开启文件系统持久化缓存
  cache: {
    type: 'filesystem',
    buildDependencies: {
      // 当这些文件变化时，清除缓存
      config: [__filename],
    },
  },
};

持久化缓存开启后，第二次构建会从磁盘加载缓存，构建时间可以缩短 80-90%。

6.2 真实 Treeshaking 验证

// 检查 Tree Shaking 效果
module.exports = {
  mode: 'production',
  optimization: {
    usedExports: true,
    sideEffects: true,
  },
};

通过 npx rspack build --analyze 可以可视化查看哪些导出被 Tree Shaking 移除。

6.3 Module Federation（模块联邦）

Rspack 完整支持 Webpack 5 的 Module Federation，这是 Rspack 最具战略意义的能力之一——它让多个独立构建的应用可以在运行时共享模块：

// host/rspack.config.js — 应用 A（主机）
module.exports = {
  plugins: [
    new rspack.container.ModuleFederationPlugin({
      name: 'host',
      shared: ['react', 'react-dom'],
      exposes: {
        './Header': './src/components/Header',
      },
    }),
  ],
};

// remote/rspack.config.js — 应用 B（远程）
module.exports = {
  plugins: [
    new rspack.container.ModuleFederationPlugin({
      name: 'remote',
      shared: ['react', 'react-dom'],
      remotes: {
        host: 'host@http://localhost:3000/remoteEntry.js',
      },
    }),
  ],
};

浏览器
├── http://localhost:3000 (host)
│   └── 加载 remoteEntry.js → 使用 remote 的组件
└── http://localhost:3001 (remote)
    └── 加载 host 的 Header 组件

Module Federation 使得：

• 微前端架构不需要 iframe 或单仓
• 跨团队共享组件库不需要 npm 发布
• 运行时按需加载替代构建时打包

七、2026 年的 Rspack 生态全景

经过几年的发展，Rspack 生态已经从单一的构建工具演变成了一个完整的工具链：

生态矩阵

与 Bun 的对比

这里有一个有趣的对比值得展开：Bun 是用 Zig（后来迁移到 Rust）重写了 JavaScript 运行时，而 Rspack 是用 Rust 重写了 JavaScript 构建工具。两者都瞄准了 Node.js 的性能瓶颈，但层级不同：

Node.js 运行时层 ──→ Bun (替换运行时)
Node.js 构建工具层 ──→ Rspack (替换构建引擎)

两者可以共存——Bun 作为包管理器和运行时，Rspack 作为构建工具，这是 2026 年字节跳动推荐的现代前端工程化栈。

八、总结：Rspack 在前端工具链中的位置

Rspack 的出现解决了一个根本矛盾：Webpack 生态的丰富性和 JavaScript 语言性能之间的矛盾。通过 Rust 的系统级性能和 Node-API 的生态桥接，它让团队不需要在"快"和"生态丰富"之间做二选一。

Rspack 的核心价值：

1. 性能跃升：基于 Rust 的并行构建和 SWC 的极速转译，冷启动和热更新速度提升 5-10 倍
2. 零成本迁移：兼容 Webpack 配置，现有项目几乎不需要改代码
3. 生态完整：Loader、Plugin、Module Federation 全都支持
4. 企业级验证：字节跳动内部数千个项目、数万工程师的生产验证

适用场景：

• 中大型前端项目（100+ 模块）
• 需要持续维护的长期项目
• 从 Webpack 迁移但不想重构配置的团队
• 需要高性能 HMR 的开发团队

不适用场景：

• 小型项目（Vite 的开发体验仍然更优雅）
• 需要深度自定义 Webpack 内部行为的项目（Rspack 仍在追赶 Hooks 覆盖度）
• 非浏览器目标为主的项目（但 Rspack 正在扩展 Node.js 和跨端支持）

展望： 随着 Rspack 1.x 的发布和 Rsbuild 的成熟，字节跳动的这套"Rust 前端工具链"正在从内部走向开源生态的舞台中央。Bun + Rspack 的组合，代表了 2026 年前端工程化性能优化的最佳路径。对于还在用 Webpack 的团队来说，现在是一个认真考虑迁移的时机——不是因为 Webpack 有问题，而是因为 Rspack 解决了那个你每天都在忍受、却习以为常的痛苦。

本文档版本：2026-07-02 | 选题来源：Go语言 Web开发 / 前端构建工具链最新发布