Rspack 1.5 深度实战：当 Rust 重写前端构建的最后一公里——从 Barrel 文件优化到 React Compiler 原生集成、从纯函数 Tree Shaking 到运行时模式实验的生产级完全指南（2026）

引言：前端构建工具的 Rust 终局之战

2026 年 6 月 18 日，Rspack 1.5 正式发布。这个版本不是一个简单的迭代——它标志着 Rust 重写前端构建工具链的最后一公里终于被打通了。

为什么这么说？因为 Rspack 1.5 解决的不再是"能不能跑"的问题，而是"跑得好不好"的问题。Barrel 文件优化消除了前端项目中最隐蔽的性能黑洞；React Compiler 原生集成让 Rspack 成了 React 生态的一等公民；纯函数 Tree Shaking 默认启用意味着你什么都不用配就能拿到更小的包；运行时模式实验指向了 Rspack 2.0 的架构方向。

如果你还在用 Webpack，这篇文章会告诉你为什么要认真考虑迁移。如果你已经在用 Rspack 1.x，这篇文章会帮你榨干 1.5 的每一个新特性。

一、Rspack 的 Rust 架构：为什么性能差距越拉越大

1.1 从 Webpack 到 Rspack：不是换语言，是换架构

Webpack 的核心问题不是 JavaScript 慢，而是架构本身就是 O(n²) 的。每一个模块都要经过完整的 loader 链，每一次构建都要从头走完整个 dependency graph。在大型项目中，这导致了两个致命问题：

• 冷启动 O(n²)：模块数翻倍，启动时间翻四倍
• HMR 线性增长：改一行代码的反馈时间随项目规模线性增长

Rspack 的 Rust 实现不是简单的语言翻译。它重新设计了整个构建管线：

Webpack:  Source → Loader Chain → Parser → Dependency Graph → Chunk → Bundle
Rspack:   Source → Builtin SWC → Incremental Graph → Parallel Chunk → Lazy Bundle

关键差异在于：

1. SWC 内置：不需要 Node.js 进程间通信的开销
2. 增量图计算：只重新计算变化的部分
3. 并行分块：Chunk 生成完全并行化
4. 惰性打包：只在需要时才生成最终 bundle

1.2 1.5 的性能精进：从微秒到毫秒的极致优化

Rspack 1.5 包含了 15+ 项性能优化，每一项看似微不足道，但叠加后的效果是惊人的。让我挑几个最值得关注的深入分析。

1.2.1 移除 serde_json：用 Simdjson 替代

// 1.4: 使用 serde_json 解析
let data: Value = serde_json::from_str(&json_str)?;

// 1.5: 使用 simdjson 风格的零拷贝解析
let data = simd_json::from_str(&mut json_str)?;

在大型项目中，package.json、tsconfig.json、.babelrc 等 JSON 文件的数量可能达到数百个。serde_json 的问题在于它需要先分配完整的 Value 树，然后再遍历。Simdjson 风格的解析器利用 SIMD 指令直接在原始字节上操作，跳过了中间分配。

实测数据（10 万行 JSON）：

1.2.2 减少 memcpy：Rust 所有权模型的正确用法

// 1.4: 不必要的拷贝
fn process_module(module: &Module) -> ProcessedModule {
    let source = module.source().to_vec(); // 拷贝!
    ProcessedModule::new(source)
}

// 1.5: 利用所有权避免拷贝
fn process_module(module: Module) -> ProcessedModule {
    // 直接移动所有权，零拷贝
    ProcessedModule::from_raw(module.into_source())
}

这个改动看似简单，但在处理 10 万+ 模块的项目中，累计减少的内存拷贝可以节省数百毫秒的构建时间。

1.2.3 ASCII 快速路径：依赖位置计算的优化

// 1.5 新增：ASCII 快速路径
fn compute_dependency_location(source: &str) -> Location {
    // 如果源码是纯 ASCII（大多数 JS 模块是），
    // 跳过 UTF-8 解码，直接按字节计算
    if source.is_ascii() {
        compute_location_ascii(source.as_bytes())
    } else {
        compute_location_utf8(source)
    }
}

这个优化的精妙之处在于它利用了一个统计事实：超过 95% 的 JavaScript 模块源码是纯 ASCII 的。对于 ASCII 字符串，不需要处理多字节 UTF-8 序列，直接按字节遍历即可。

1.2.4 DFA 自动机优化内容哈希扫描

// 1.4: 正则表达式扫描内容哈希
let hash = compute_content_hash_regex(&source);

// 1.5: 强制使用 DFA 自动机
let hash = compute_content_hash_dfa(&source);

正则表达式引擎有两种实现：NFA（非确定性有限自动机）和 DFA（确定性有限自动机）。NFA 支持更多语法特性但有回溯风险，DFA 没有回溯但内存占用更高。Rspack 1.5 在内容哈希计算中强制使用 DFA，消除了正则回溯导致的性能尖刺。

1.3 实战：大型项目迁移 Rspack 的性能对比

以一个典型的中大型 React 项目为例（500+ 组件，1200+ 模块）：

注意 1.4 到 1.5 的改进不是大版本号带来的飞跃，而是 15 项微优化叠加的结果。这就是 Rust 的优势——底层优化的天花板极高。

二、Barrel 文件优化：消灭前端项目中最隐蔽的性能黑洞

2.1 什么是 Barrel 文件？为什么它是问题？

Barrel 文件（也叫 index 文件）是前端项目中极其常见的模式：

// components/index.ts — 一个典型的 Barrel 文件
export { Button } from './Button';
export { Input } from './Input';
export { Select } from './Select';
export { Modal } from './Modal';
export { Table } from './Table';
export { DatePicker } from './DatePicker';
// ... 导出 50+ 个组件

看起来很整洁，对吧？但这个文件在构建时会造成严重的问题：

问题 1：全量解析

当你只用了 Button：

import { Button } from './components';

打包器必须先解析 components/index.ts，发现它导出了 50+ 个模块，然后逐个加载和解析这些模块——即使你只需要一个 Button。

问题 2：Tree Shaking 的困境

即使打包器知道你只用了 Button，它也不能简单地移除其他模块，因为：

1. 被导出的模块可能有副作用（side effects）
2. 重导出（re-export）创建了新的依赖边，打包器必须保守处理

问题 3：依赖图膨胀

每个通过 Barrel 文件导入的模块都会在依赖图中创建额外的边。对于 n 个导出的 Barrel 文件，依赖图的边数从 O(n) 增长到 O(n²)。

2.2 Rspack 1.5 的 Barrel 文件优化方案

Rspack 1.5 引入了智能的 Barrel 文件优化，核心思路是：在模块图构建阶段就识别 Barrel 模式，跳过不需要的重导出链。

// rspack.config.ts
export default {
  optimization: {
    barrel: {
      // 启用 Barrel 文件优化
      enabled: true,
      // 哪些文件被视为 Barrel 文件
      test: /\/index\.[jt]sx?$/,
      // 最小导出数量阈值
      minExports: 3,
    },
  },
};

2.2.1 优化原理：从 O(n²) 到 O(1)

传统路径：

你的代码 → import { Button } → components/index.ts → 解析所有 50 个 export → 加载 Button.tsx
                                                                                   → 加载 Input.tsx (浪费!)
                                                                                   → 加载 Select.tsx (浪费!)
                                                                                   → ...

Rspack 1.5 优化路径：

你的代码 → import { Button } → 直接重写为 import { Button } from './components/Button'
                               → 只加载 Button.tsx

这个重写发生在模块解析阶段，比 Tree Shaking 更早，因此不会产生任何多余的模块加载开销。

2.2.2 与 Webpack 的 sideEffects 字段对比

Webpack 通过 package.json 的 sideEffects 字段来标记无副作用的模块：

{
  "sideEffects": false
}

这个方案的问题在于：

1. 全有或全无：要么整个包无副作用，要么没有优化
2. 维护负担：需要手动维护副作用列表
3. 信任模型：声明为无副作用但实际有副作用的模块会导致运行时错误

Rspack 的 Barrel 文件优化不需要 sideEffects 声明，它通过静态分析自动判断：

// Rspack 内部逻辑（伪代码）
fn is_barrel_module(module: &Module) -> bool {
    // 1. 模块只包含 export 语句
    // 2. 所有 export 都是 re-export（from 其他模块）
    // 3. 没有副作用代码（没有顶层语句）
    module.body.iter().all(|stmt| {
        matches!(stmt, Statement::ExportReExport(_))
    })
}

2.2.3 实战效果

在一个使用 Ant Design 5 + React 的大型项目中：

// 优化前：使用 Ant Design 的 Barrel 导入
import { Button, Input, Select } from 'antd';

// Rspack 1.5 自动优化为（内部重写，源码不变）：
import Button from 'antd/es/button';
import Input from 'antd/es/input';
import Select from 'antd/es/select';

2.3 Barrel 文件优化的注意事项

2.3.1 有副作用的 Barrel 文件

如果你的 Barrel 文件包含副作用代码：

// components/index.ts — 有副作用！
export { Button } from './Button';
export { Input } from './Input';

// 这行是副作用
console.log('Components loaded');

// 或者这样
import './globalStyles.css';

Rspack 会检测到这不是纯 Barrel 文件，跳过优化。这是安全的，但意味着你拿不到优化收益。最佳实践是保持 Barrel 文件纯净。

2.3.2 循环依赖

Barrel 文件优化可能暴露之前被掩盖的循环依赖问题：

A/index.ts → re-export A/foo.ts
A/foo.ts → import B/bar.ts
B/index.ts → re-export B/bar.ts
B/bar.ts → import A/foo.ts

优化前，循环依赖被模块缓存机制掩盖了。优化后，直接导入绕过了缓存，可能导致未初始化的导出。解决方案是修复循环依赖本身。

三、React Compiler 原生集成：Rspack 成为 React 生态的一等公民

3.1 React Compiler 是什么？

React Compiler（原名 React Forget）是 React 团队开发的自动记忆化编译器。它的核心功能是：

1. 自动 memo：不需要手动写 useMemo、useCallback、React.memo
2. 细粒度更新：只重新计算真正变化的值
3. 性能保证：消除因为不必要的重新渲染导致的性能问题

在没有 Compiler 之前，你需要这样写：

// 手动优化的 React 组件
const ExpensiveList = React.memo(({ items, filter }: Props) => {
  const filtered = useMemo(() => 
    items.filter(item => item.category === filter), 
    [items, filter]
  );
  
  const handleClick = useCallback((id: string) => {
    console.log('clicked', id);
  }, []);
  
  return (
    <ul>
      {filtered.map(item => (
        <li key={item.id} onClick={() => handleClick(item.id)}>
          {item.name}
        </li>
      ))}
    </ul>
  );
});

有了 React Compiler，你只需要写最自然的代码：

// React Compiler 自动优化
const ExpensiveList = ({ items, filter }: Props) => {
  const filtered = items.filter(item => item.category === filter);
  
  const handleClick = (id: string) => {
    console.log('clicked', id);
  };
  
  return (
    <ul>
      {filtered.map(item => (
        <li key={item.id} onClick={() => handleClick(item.id)}>
          {item.name}
        </li>
      ))}
    </ul>
  );
};

Compiler 会自动插入记忆化代码，效果等同于手动优化版本。

3.2 Rspack 1.5 的原生集成方案

在 1.5 之前，要在 Rspack 中使用 React Compiler，你需要安装 babel-plugin-react-compiler 并配置 Babel，这会增加额外的编译开销：

// 1.4 的方案：通过 Babel 插件
export default {
  module: {
    rules: [{
      test: /\.[jt]sx?$/,
      use: [{
        loader: 'babel-loader',
        options: {
          plugins: ['babel-plugin-react-compiler'],
        },
      }],
    }],
  },
};

1.5 的方案直接集成到 SWC 中，零额外开销：

// 1.5 的方案：原生 SWC 集成
export default {
  module: {
    rules: [{
      test: /\.[cm]?[jt]sx?$/,
      loader: 'builtin:swc-loader',
      options: {
        jsc: {
          transform: {
            reactCompiler: true,  // 一行配置，开启 React Compiler
          },
        },
      },
    }],
  },
};

3.2.1 为什么 SWC 集成比 Babel 插件快？

Babel 方案：JSX → Babel Parse → Babel Transform (React Compiler) → Babel Generate → SWC Parse → SWC Transform → Output
              ████████████████████████████████████████████████████████████████████████████████████████████████
              两次解析 + 两次转换 + 一次生成 = 5 步

SWC 方案：  JSX → SWC Parse → SWC Transform (内置 React Compiler) → Output
              ████████████████████████████████████████████████████████
              一次解析 + 一次转换 + 一次生成 = 3 步

关键差异在于 SWC 的 React Compiler 实现是 Rust 原生的，不需要经过 Babel 的 JavaScript AST。实测数据：

3.3 React Compiler 的编译产物分析

让我们看看 React Compiler 到底做了什么：

// 输入代码
function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState(null);
  const displayName = user?.name ?? 'Loading...';
  
  useEffect(() => {
    fetchUser(userId).then(setUser);
  }, [userId]);
  
  return <h1>{displayName}</h1>;
}

编译后（简化版）：

// React Compiler 输出
function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  
  // Compiler 自动插入的缓存变量
  let displayName = useMemoCache(1);
  if (displayName === undefined || displayName[0] !== user?.name) {
    displayName = useMemoCache(1, user?.name ?? 'Loading...');
  }
  
  useEffect(() => {
    fetchUser(userId).then(setUser);
  }, [userId]);
  
  return <h1>{displayName}</h1>;
}

Compiler 做了什么：

1. 识别 displayName 是 user?.name 的派生值
2. 插入缓存逻辑，只在 user?.name 变化时重新计算
3. 在这个简单例子中效果不明显，但在复杂组件中效果巨大

3.4 实战：大型 React 项目接入 React Compiler

// rspack.config.ts — 完整配置
import { defineConfig } from '@rspack/cli';

export default defineConfig({
  module: {
    rules: [{
      test: /\.[cm]?[jt]sx?$/,
      loader: 'builtin:swc-loader',
      options: {
        jsc: {
          transform: {
            reactCompiler: {
              // 启用编译器
              target: '18',        // 目标 React 版本
              panicThreshold: 'ALL_ERRORS', // 编译错误处理策略
            },
          },
          parser: {
            syntax: 'typescript',
            tsx: true,
          },
        },
      },
      type: 'javascript/auto',
    }],
  },
  
  // React Compiler 的运行时依赖
  plugins: [
    new rspack.ProvidePlugin({
      // 自动注入 useMemoCache
      useMemoCache: ['react-compiler-runtime', 'c'],
    }),
  ],
});

3.4.1 渐进式迁移策略

如果你有大量存量代码，建议分阶段接入：

// 阶段 1：只对特定目录启用
export default {
  module: {
    rules: [{
      test: /\.[cm]?[jt]sx?$/,
      include: /src\/features\/new-module/, // 只对新模块启用
      loader: 'builtin:swc-loader',
      options: {
        jsc: {
          transform: { reactCompiler: true },
        },
      },
    }, {
      // 其他文件不启用
      test: /\.[cm]?[jt]sx?$/,
      exclude: /src\/features\/new-module/,
      loader: 'builtin:swc-loader',
    }],
  },
};

// 阶段 2：在文件级别用注释控制
/* @reactCompilerEnable */
export function MyComponent() {
  // 这个组件会被 Compiler 处理
}

/* @reactCompilerDisable */
export function LegacyComponent() {
  // 这个组件不会被 Compiler 处理
  // 适合有不兼容模式的旧代码
}

四、纯函数 Tree Shaking：默认启用，零配置更小的包

4.1 从 sideEffects 到纯函数标注

Tree Shaking 有两个层次：

1. 模块级：移除未使用的模块（sideEffects: false 解决的）
2. 语句级：移除未使用的函数调用（纯函数标注解决的）

Rspack 1.5 默认启用的 pureFunctions 就是第二个层次。

// 问题代码
import { analytics } from './analytics';

function App() {
  // analytics.track 只在开发时有用
  if (process.env.NODE_ENV === 'development') {
    analytics.track('app_loaded');
  }
}

// 生产构建中，即使 if 分支被移除，
// analytics 模块仍然会被打包进来

4.2 @__NO_SIDE_EFFECTS__ 标注

Rspack 1.5 支持 @__NO_SIDE_EFFECTS__ 标注，让打包器知道某个函数是纯函数：

// utils.ts
/** @__NO_SIDE_EFFECTS__ */
export function formatDate(date: Date, locale: string): string {
  return new Intl.DateTimeFormat(locale).format(date);
}

/** @__NO_SIDE_EFFECTS__ */
export function debounce<T extends (...args: any[]) => any>(
  fn: T,
  ms: number
): (...args: Parameters<T>) => void {
  let timer: ReturnType<typeof setTimeout>;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), ms);
  };
}

/** @__NO_SIDE_EFFECTS__ */
export function deepClone<T>(obj: T): T {
  return structuredClone(obj);
}

当这些函数的返回值未被使用时，Rspack 会自动移除调用：

// 源码
import { formatDate, debounce, deepClone } from './utils';

function handler() {
  const formatted = formatDate(new Date(), 'zh-CN');
  console.log(formatted);
  
  // 这些调用的返回值没有使用
  debounce(() => {}, 100);  // 将被移除
  deepClone({ a: 1 });      // 将被移除
}

4.3 跨模块边界追踪

1.5 的一大突破是纯函数标注可以跨越模块边界：

// lib.ts
/** @__NO_SIDE_EFFECTS__ */
export function createValidator(schema: Schema) {
  return (data: unknown) => {
    // 验证逻辑，纯计算
    return schema.safeParse(data);
  };
}

// barrel.ts
import { createValidator } from './lib';

// 重导出：1.5 能追踪到 createValidator 是纯函数
export { createValidator };

// app.ts
import { createValidator } from './barrel';

// 即使经过 barrel 重导出，
// 1.5 仍然知道 createValidator 是纯函数
// 如果返回值未使用，调用会被移除
const validator = createValidator(userSchema);

在 1.4 中，经过 barrel 重导出后，纯函数信息会丢失。1.5 通过增强的模块图分析解决了这个问题。

4.4 pureFunctions 配置

除了注解，你还可以通过配置声明纯函数：

// rspack.config.ts
export default {
  experiments: {
    pureFunctions: {
      // 默认在 production 模式启用
      // 可以手动添加纯函数列表
      functions: [
        'console.log',       // 生产环境通常不需要
        'console.debug',
        'console.info',
      ],
    },
  },
};

4.5 实战：纯函数 Tree Shaking 在 UI 库中的收益

以一个典型的 UI 组件库为例：

// ui-lib/src/index.ts
export { Button } from './Button';
export { Modal } from './Modal';
export { Toast } from './Toast';

// 工具函数
export { formatDate } from './utils/date';
export { formatCurrency } from './utils/currency';
export { classNames } from './utils/classNames';

在项目中只用到了 Button 和 formatDate：

import { Button, formatDate } from 'ui-lib';

注意全量使用时没有减少，因为纯函数 Tree Shaking 只移除未使用的调用，不影响正常使用的代码。

五、运行时模式实验：Rspack 2.0 的架构预告

5.1 从构建时到运行时

Rspack 1.5 引入了实验性的 runtimeMode，这是一个面向未来的特性。当前的 Rspack 运行时（模块加载、chunk 管理、HMR）是编译时生成并内联到产物中的。runtimeMode 允许你选择不同的运行时策略：

// rspack.config.ts
export default {
  experiments: {
    runtimeMode: 'lightweight', // 实验性
  },
};

5.1.1 当前运行时的问题

Webpack/Rspack 的运行时代码大致如下：

// 生成的运行时代码（简化）
var __webpack_modules__ = {
  "./src/App.tsx": (module, __webpack_exports__, __webpack_require__) => {
    // 模块代码
  },
  // ... 数百个模块
};

var __webpack_module_cache__ = {};

function __webpack_require__(moduleId) {
  // 检查缓存
  if (__webpack_module_cache__[moduleId]) {
    return __webpack_module_cache__[moduleId].exports;
  }
  // 创建缓存并执行模块
  var module = (__webpack_module_cache__[moduleId] = {
    exports: {},
  });
  __webpack_modules__[moduleId](module, module.exports, __webpack_require__);
  return module.exports;
}

问题在于：

1. 运行时体积：每个 chunk 都包含完整的运行时代码（~2KB），在多 chunk 场景下浪费严重
2. 全局污染：运行时变量可能与其他脚本冲突
3. 不可优化：运行时代码是字符串拼接的，无法被下游工具优化

5.1.2 轻量级运行时模式

runtimeMode: 'lightweight' 的思路是：

1. 将运行时代码提取为独立模块
2. 使用原生 ESM 加载替代自定义 require
3. 利用浏览器原生模块系统减少运行时体积

// lightweight 模式的运行时（概念性）
// 不再需要 __webpack_require__，使用原生 import()
const chunkMapping = {
  "src_App_tsx": () => import("./src_App_tsx.js"),
};

async function loadChunk(id: string) {
  const loader = chunkMapping[id];
  if (!loader) throw new Error(`Chunk ${id} not found`);
  return loader();
}

5.2 运行时模式的实战考量

目前 runtimeMode 还是实验性的，不建议在生产环境使用。但了解它的方向对架构决策很重要：

1. 如果你的项目计划在 2027 年迁移到 ESM-only：runtimeMode: 'lightweight' 会是最佳选择
2. 如果需要兼容旧浏览器：继续使用默认运行时
3. 如果使用 Module Federation：需要等待 runtimeMode 对 Module Federation 的支持

六、持久化缓存增强：maxAge 与 maxGenerations

6.1 1.4 的缓存问题

Rspack 1.4 的持久化缓存配置很简单：

export default {
  cache: {
    type: 'filesystem',
  },
};

问题是缓存会无限增长。在大型项目中，缓存目录可能增长到数 GB，反而导致性能下降（因为磁盘 I/O 变慢了）。

6.2 1.5 的新配置

export default {
  cache: {
    type: 'filesystem',
    // 新增：缓存最大存活时间（秒）
    maxAge: 60 * 60 * 24 * 7, // 7 天
    // 新增：最大缓存代数
    maxGenerations: 5,
    // 新增：缓存读写计时日志
    buildDependencies: [__filename],
  },
};

6.2.1 maxAge 的含义

maxAge 控制缓存条目的最大存活时间。超过这个时间的缓存条目会在下次构建时被清理。

// 典型配置
maxAge: 60 * 60 * 24 * 7  // 7 天

// 激进配置（CI 环境）
maxAge: 60 * 60 * 24  // 1 天

// 保守配置（长期项目）
maxAge: 60 * 60 * 24 * 30  // 30 天

6.2.2 maxGenerations 的含义

maxGenerations 控制缓存代数。每次成功的构建会创建一个新的缓存代。当代数超过 maxGenerations 时，最老的代会被清理。

// 典型配置
maxGenerations: 5  // 保留最近 5 次成功构建的缓存

// CI 环境（磁盘空间有限）
maxGenerations: 2

// 开发环境（频繁切换分支）
maxGenerations: 10

6.2.3 缓存读写计时

1.5 新增了缓存读写计时日志，帮助你了解缓存的实际效果：

export default {
  cache: {
    type: 'filesystem',
    maxAge: 604800,
    maxGenerations: 5,
  },
  infrastructureLogging: {
    level: 'info',
  },
};

运行 rspack build 时，你会看到类似输出：

[persistent cache] read cache in 134ms
[persistent cache] write cache in 287ms (entries: 2847, size: 156MB)

七、模块联邦（Module Federation）运行时提升

7.1 Module Federation 的当前痛点

Module Federation 是微前端架构的核心技术，但它的运行时开销一直是痛点：

1. 初始化慢：需要先加载远程入口，解析依赖映射，再加载实际模块
2. 错误处理差：远程模块加载失败时，整个应用可能崩溃
3. HMR 不支持：开发时修改远程模块无法热更新

7.2 1.5 的运行时改进

// rspack.config.ts — 模块联邦配置
const { ModuleFederationPlugin } = require('@rspack/core');

export default {
  plugins: [
    new ModuleFederationPlugin({
      name: 'host',
      remotes: {
        remote1: 'remote1@http://localhost:3001/remoteEntry.js',
      },
      shared: {
        react: { singleton: true },
        'react-dom': { singleton: true },
      },
    }),
  ],
};

1.5 的运行时改进主要体现在：

1. 预加载提示：在 HTML 中自动插入 <link rel="modulepreload">，让浏览器提前下载远程入口
2. 更快的依赖解析：优化了共享模块的版本比对算法
3. 更好的错误边界：远程模块加载失败时提供更清晰的错误信息

7.3 实战：构建高性能微前端

// host/rspack.config.ts
import { defineConfig } from '@rspack/cli';
import { ModuleFederationPlugin } from '@rspack/core';

export default defineConfig({
  plugins: [
    new ModuleFederationPlugin({
      name: 'host',
      filename: 'remoteEntry.js',
      exposes: {
        './MainLayout': './src/layouts/MainLayout',
        './AuthModule': './src/modules/Auth',
      },
      remotes: {
        dashboard: 'dashboard@http://localhost:3001/remoteEntry.js',
        settings: 'settings@http://localhost:3002/remoteEntry.js',
      },
      shared: {
        react: { 
          singleton: true, 
          eager: true,  // 1.5 改进了 eager 加载策略
          requiredVersion: '^18.0.0',
        },
        'react-dom': { 
          singleton: true,
          eager: true,
        },
        'react-router-dom': {
          singleton: true,
        },
      },
    }),
  ],
});

八、Seal 阶段性能优化：生产构建的最后一道加速

8.1 什么是 Seal 阶段？

Webpack/Rspack 的构建流程大致分为三个阶段：

1. Make 阶段：解析模块，构建依赖图
2. Seal 阶段：根据依赖图生成 Chunk，优化代码
3. Emit 阶段：输出文件到磁盘

Seal 阶段是最耗时的，因为涉及：

• Chunk 分割策略
• 代码压缩
• 内容哈希计算
• 运行时代码注入

8.2 1.5 的 Seal 阶段优化

// 1.5 的 Seal 阶段优化（简化）

// 优化 1：减少 Build Chunk Graph 的准备工作
// 1.4 中，每次都要重新计算所有 chunk 的依赖关系
// 1.5 中，增量计算只处理变化的 chunk
fn build_chunk_graph_incremental(&mut self, changed_modules: &[ModuleId]) {
    // 找到受影响的 chunk
    let affected_chunks = self.find_affected_chunks(changed_modules);
    // 只重新计算这些 chunk 的依赖关系
    for chunk in affected_chunks {
        self.recalculate_chunk_dependencies(chunk);
    }
}

// 优化 2：模块拼接优化遍历
// 1.4 中，模块拼接（ModuleConcatenation）是全图遍历
// 1.5 中，使用拓扑排序 + 剪枝
fn optimize_module_concatenation(&mut self) {
    let sorted = topological_sort(&self.module_graph);
    for module in sorted {
        if self.can_concatenate(module) {
            self.concatenate(module);
        } else {
            // 剪枝：如果当前模块不能拼接，
            // 它的子模块也不需要检查
            continue;
        }
    }
}

// 优化 3：Flag Dependency Usage Key 分配优化
// 1.4 中，每个导出都要分配一个唯一的 key
// 1.5 中，使用位掩码减少分配
fn allocate_usage_keys(&mut self) {
    let mut mask: u64 = 0;
    for export in &self.exports {
        export.usage_key = mask;
        mask <<= 1;
        if mask == 0 { mask = 1; }
    }
}

8.3 安装体积优化

1.5 还对 Rspack 自身的安装体积进行了优化：

减少了 27.6% 的安装体积，主要来自：

1. 移除未使用的 SWC 特性（wasm 文件）
2. 压缩平台特定的二进制文件
3. 精简依赖树

九、Rsbuild 1.5、Rslint、Rspress 2.0：Rspack 生态的全线升级

Rspack 不是一个孤立的工具，它是整个 Rs 生态的核心引擎。1.5 发布的同时，生态内的其他工具也同步升级。

9.1 Rsbuild 1.5

Rsbuild 是 Rspack 的高层封装，提供开箱即用的开发体验：

// rsbuild.config.ts
import { defineConfig } from '@rsbuild/core';
import { pluginReact } from '@rsbuild/plugin-react';

export default defineConfig({
  plugins: [pluginReact()],
  // 自动继承 Rspack 1.5 的所有优化
  tools: {
    rspack: {
      experiments: {
        pureFunctions: true,
      },
    },
  },
});

9.2 Rslint

Rslint 是基于 Rspack 基础设施构建的 Linter，利用 Rspack 的模块解析能力提供更准确的规则检查：

# 安装
npm install -D @rslint/core

# 运行
npx rslint check src/

9.3 Rspress 2.0 beta

Rspress 是基于 Rspack 的静态站点生成器，2.0 beta 带来了：

• MPA（多页应用）模式
• 更快的构建速度
• 更好的主题系统

十、从 Webpack 迁移到 Rspack 1.5 的完整指南

10.1 迁移评估清单

在迁移前，先评估你的项目：

# 使用官方兼容性检查工具
npx @rspack/check-webpack-compat --config webpack.config.js

关键检查项：

1. Loader 兼容性：大部分 Webpack loader 可以直接使用
2. Plugin 兼容性：Rspack 兼容大部分 Webpack 插件 API
3. 自定义 loader/plugin：需要逐一验证

10.2 迁移步骤

# 1. 安装 Rspack
npm install -D @rspack/core @rspack/cli

# 2. 重命名配置文件
mv webpack.config.js rspack.config.ts

# 3. 修改配置（主要改动点）

// rspack.config.ts — 从 Webpack 迁移的关键改动

// 改 1：替换 webpack 为 @rspack/core
// const webpack = require('webpack');
import * as rspack from '@rspack/core';

export default {
  // 改 2：使用 builtin:swc-loader 替代 babel-loader
  module: {
    rules: [{
      test: /\.[jt]sx?$/,
      // 删除 babel-loader，使用内置 SWC
      loader: 'builtin:swc-loader',
      options: {
        jsc: {
          parser: {
            syntax: 'typescript',
            tsx: true,
          },
          transform: {
            reactCompiler: true, // 顺便开启 React Compiler
          },
        },
      },
    }],
  },

  // 改 3：启用 1.5 新特性
  experiments: {
    pureFunctions: true,
  },
  
  cache: {
    type: 'filesystem',
    maxAge: 604800,
    maxGenerations: 5,
  },

  // 大部分 plugin 可以直接使用
  plugins: [
    new rspack.HtmlRspackPlugin({
      template: './public/index.html',
    }),
    new rspack.DefinePlugin({
      'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV),
    }),
  ],
};

10.3 常见迁移问题

问题 1：__non_webpack_require__ 不支持

// Webpack 中的特殊用法
if (typeof __non_webpack_require__ !== 'undefined') {
  __non_webpack_require__('some-module');
}

// Rspack 替代方案
if (typeof require !== 'undefined') {
  eval('require')('some-module');
}

问题 2：自定义 loader 的 this.callback 签名差异

// Webpack loader
module.exports = function(source) {
  this.callback(null, source, map);
  return;
};

// Rspack 兼容写法
module.exports = function(source) {
  // Rspack 的 this.callback 签名与 Webpack 一致
  // 但 sourceMap 参数格式可能不同
  this.callback(null, source, this.sourceMap ? map : undefined);
  return;
};

问题 3：MiniCssExtractPlugin 的替代

// Webpack
const MiniCssExtractPlugin = require('mini-css-extract-plugin');

// Rspack 使用内置的 CSS 提取
import * as rspack from '@rspack/core';

export default {
  plugins: [
    new rspack.CssExtractRspackPlugin({
      filename: '[name].[contenthash].css',
    }),
  ],
  module: {
    rules: [{
      test: /\.css$/,
      use: [rspack.CssExtractRspackPlugin.loader, 'css-loader'],
    }],
  },
};

十一、性能对比：Rspack 1.5 vs Webpack 5 vs Vite vs Turbopack

11.1 冷启动性能

注意 Vite 的冷启动看起来很快，但那是开发服务器的启动时间，不包含预构建。首次访问时 Vite 还需要按需编译每个模块。

11.2 生产构建性能

Rspack 在生产构建中的优势最为明显，因为 Rust 的并行计算能力在 CPU 密集型任务中发挥到了极致。

11.3 HMR 性能

十二、总结与展望

12.1 Rspack 1.5 的核心价值

Rspack 1.5 不是一个革命性的版本，但它是所有 1.x 版本中最实用的。核心价值总结：

1. Barrel 文件优化：自动消灭前端项目中最常见的性能黑洞，零配置收益巨大
2. React Compiler 原生集成：SWC 级别的性能，让 React 的自动记忆化不再是性能负担
3. 纯函数 Tree Shaking：默认启用，跨模块边界追踪，让产物更小
4. 运行时模式实验：指向 Rspack 2.0 的方向，原生 ESM 运行时
5. 持久化缓存增强：maxAge + maxGenerations 解决缓存无限增长问题
6. Seal 阶段优化：生产构建的最后一道加速

12.2 什么时候应该迁移到 Rspack？

• 立即迁移：如果你的项目使用 Webpack 5 且构建时间超过 30 秒
• 计划迁移：如果你使用 Vite 但遇到 Rollup 的兼容性问题
• 观望：如果你的项目很小（< 100 模块），当前工具已经够用
• 等待：如果你依赖 Webpack 5 的特定插件，且该插件没有 Rspack 兼容版本

12.3 Rspack 2.0 展望

基于 1.5 的 runtimeMode 实验和 Rspack 团队的公开路线图，2.0 可能的方向：

1. 原生 ESM 运行时：完全基于浏览器的 ES Module 系统
2. 更智能的增量编译：基于文件内容而非时间戳的缓存验证
3. 与 AI 工具的深度集成：构建配置的 AI 辅助优化
4. 更完善的 Plugin API：支持更复杂的自定义构建逻辑

Rspack 1.5 证明了一件事：前端构建工具的 Rust 重写不是营销噱头，而是实实在在的性能革命。从 1.0 的"能用"到 1.5 的"好用"，Rspack 正在快速逼近 Webpack 生态兼容性的终点线。如果你还在犹豫，现在就是最好的迁移时机。