🐢 前端构建的「等待之痛」#

有没有这样的经历：早上到公司，改了 3 行 CSS，然后盯着终端看了 30 秒等 HMR 刷新？

「前端构建慢」这个问题困扰了我们快十年。2015 年用 Webpack 1.x 的时候慢，2025 年用 Webpack 5.x 的时候还是慢。不是 Webpack 不好——它在设计之初就做了很多正确的事情，只是 JavaScript 做编译这件事，本质上就是在用螺丝刀挖地。

好在 2026 年，我们终于有了更好的选择。

⚡ 两匹 Rust 黑马#

1
// 从 Webpack 迁移到 Rspack——配置文件几乎不用改
2
const path = require('path');
3

4
module.exports = {
5
  entry: './src/index.tsx',
6
  output: {
7
    path: path.resolve(__dirname, 'dist'),
8
    filename: '[name].[contenthash].js',
9
  },
10
  module: {
11
    rules: [
12
      {
13
        test: /\.tsx?$/,
14
        use: 'babel-loader',
15
        exclude: /node_modules/,
16
      },
17
      {
18
        test: /\.module\.scss$/,
19
        use: ['style-loader', 'css-loader', 'sass-loader'],
20
      },
21
    ],
22
  },
23
  plugins: [
24
    new HtmlWebpackPlugin({ template: './public/index.html' }),
25
  ],
26
};

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

4
# 运行构建——注意看时间
5
# Webpack 5: 45.2s
6
npx rspack build
7
# Rspack: 3.8s
8
# 🎉 快了 12 倍！

1
# Next.js 15+ 默认使用 Turbopack
2
# 你什么都不用改
3
npx next dev
4
# ✅ Turbopack 已自动启用
5

6
# 想确认是否在用 Turbopack？
7
# 启动日志会显示：
8
#   ▲ Next.js 15.2.0
9
#   - Turbo (beta, using turbopack)

1
# 安装 Turbopack 的独立版本
2
npm install turbo -D
3

4
# 配置文件

1
{
2
  "$schema": "https://turbo.build/schema.json",
3
  "globalDependencies": ["**/.env.*local"],
4
  "pipeline": {
5
    "build": {
6
      "dependsOn": ["^build"],
7
      "outputs": ["dist/**"]
8
    },
9
    "dev": {
10
      "cache": false
11
    }
12
  }
13
}

1
# 搭配 monorepo 使用效果最佳
2
npx turbo run build

🔬 为什么 Rust 这么快？#

这不是魔法，而是语言本身的天花板差异。看一个简单的对比：

1
// JavaScript 版本——遍历 100 万行代码并转换
2
// 这就是 Webpack 每次解析模块时在做的事
3
function processModules(modules) {
4
  return modules.map(module => ({
5
    ...module,
6
    transformed: heavyTransform(module.source),
7
    dependencies: resolveDeps(module.imports),
8
  }));
9
}
10

11
// 在 Node.js 中，这个操作的时间取决于 V8 引擎的 JIT 编译能力
12
// 而且受限于单线程和垃圾回收

1
// Rust 版本——同样的逻辑
2
// Rust 编译成原生代码，没有 JIT 预热，没有 GC 暂停
3
fn process_modules(modules: Vec<Module>) -> Vec<TransformedModule> {
4
    modules
5
        .into_par_iter() // 并行处理——零额外成本
6
        .map(|module| TransformedModule {
7
            transformed: heavy_transform(&module.source),
8
            dependencies: resolve_deps(&module.imports),
9
        })
10
        .collect()
11
}
12

13
// 优势：
14
// 1. 原生编译——没有 JIT 预热开销
15
// 2. 真正的多线程并行——没有 GIL
16
// 3. 零开销抽象——高级代码编译成高效的机器码
17
// 4. 无 GC 暂停——内存管理是确定性的

Webpack 用 JavaScript 解析一个中型项目的模块图需要数千次文件系统调用和 AST 转换，而 Rspack 用 Rust 写同样的逻辑，在解析阶段就快了 5-8 倍，再加上并行处理，总提速 10-20 倍就一点也不奇怪了。

🚀 迁移实战指南#

如果你也想从 Webpack 迁移到 Rspack，以下是我的实操经验：

1
# 使用 Rspack 提供的迁移分析工具
2
npx @rspack/analyze-config ./webpack.config.js
3

4
# 它会输出一个报告，告诉你哪些配置项可以直接迁移，
5
# 哪些需要手动适配，哪些不支持

1
# 1. 先在新分支上安装 Rspack
2
npm install @rspack/core @rspack/cli -D
3

4
# 2. 创建 rspack.config.js（从 webpack.config.js 复制修改）
5
cp webpack.config.js rspack.config.js
6

7
# 3. 在 package.json 中添加新命令
8
# "build:rspack": "rspack build -c rspack.config.js"

💭 我的看法#

2026 年，Webpack 已经不再是新项目的默认选择了。Rspack 和 Turbopack 代表了前端构建工具未来的方向——用更底层的语言重写核心，用原生性能换取开发体验的提升。

如果你的项目还在用 Webpack，我强烈建议你试试迁移到 Rspack。迁移成本很低（配置基本兼容），但收益是每天节省几分钟到几十分钟的等待时间。对于一个 10 人团队，一年下来就是上千小时的效率提升。

构建工具不应该成为开发体验的瓶颈——就像我们不再用手工打包一样，我们也不该再忍受慢吞吞的构建工具。

🧵 从 Monorepo 角度看 Rust 构建工具的真正优势#

单独说构建速度也许还不够有冲击力，但如果你在一个大型 Monorepo 中工作过，你就知道构建工具的速度直接决定了你的摸鱼时间还是干活时间。

我所在的团队维护着一个包含 30+ 个包（packages）的 Monorepo，总共有超过 2000 个 TypeScript 文件。用 Webpack 5 做一次完整的生产构建需要 3 分 12 秒，而且每天要构建十几次。CI 流水线光构建这一步就要等将近 4 分钟。切换到 Rspack 后，生产构建时间降到了 15 秒。算下来每天光是等待构建的时间就节省了将近 40 分钟——一个月就是 13 个小时，一年就是将近 7 个工作日。

而且 Rspack 在 Monorepo 场景下还有一个隐藏优势：增量编译。当你只改了一个包里的一个文件时，Rspack 只会重新编译这个包及其依赖的包，而 Webpack 会把整个依赖图重新构建一遍。在多包 Monorepo 中，这个差距会被放大到 50 倍甚至 100 倍。

⚠️ 迁移踩坑实录#

讲完了好处，来聊聊我迁移过程中遇到的坑，希望能帮你少走弯路。

坑一：css-loader 的 options 差异。 Webpack 的 css-loader 支持很多配置项，比如 modules.exportLocalsConvention。Rspack 虽然兼容大部分，但有些细枝末节的配置项不支持。我们的项目里用了 exportLocalsConvention: ‘camelCaseOnly’，迁移后在 Rspack 中需要改成内置的 CSS Modules 配置方式。这类问题通常在构建时报错，很容易定位。

坑二：某些 webpack plugin 没有 Rspack 替代品。 比如我们之前用的 CircularDependencyPlugin（检测循环依赖），在 Rspack 生态中没有现成的替代品。解决方案是在 CI 阶段用独立的工具（如 Madge）来做循环依赖检测，而不作为构建插件运行。

坑三：asset/source 引入 SVG 的行为。 我们在 React 项目中大量使用 SVGR 把 SVG 文件引入为 React 组件。在 Webpack 中通过 @svgr/webpack 处理。Rspack 虽然可以兼容 SVGR，但配置方式略有不同，需要参考迁移文档仔细调整。

坑四：HMR 的边界情况。 绝大多数情况下 Rspack 的 HMR 比 Webpack 快得多，但在一些极端情况下（比如修改了全局 CSS 变量定义），Rspack 的 HMR 会退化成全量刷新。这个问题在 Webpack 中同样存在，不是 Rspack 特有的，但遇到时容易让人怀疑是不是迁移出了问题。

总之一句话：迁移到 Rspack 是值得的，但不要在生产分支上直接切换。先在一个独立的分支上做迁移测试，确保所有功能正常后再合并到主分支。即使遇到上述问题，解决成本也远低于每天忍受慢吞吞的构建速度带来的效率损失。

🌟 展望：2027 年前端构建工具会是什么样子？#

站在 2026 年中展望未来，我看到了几个非常明确的趋势。

首先，Rust 在前端工具链中的渗透会进一步加深。除了 Rspack 和 Turbopack 这两个打包工具之外，Biome（Rust 写的 ESLint + Prettier 替代品）已经在 2026 年获得了大规模采用。Oxidation 编译器也在快速发展。前端开发者的日常工具链——从编译、打包、代码检查、格式化到测试——正在全面被 Rust 重写。这不是什么「Rust 要取代 JavaScript」的叙事，而是「用 Rust 做底层基础设施，用 JavaScript 写业务代码」的分工优化。这种各取所长的模式才是最高效的。

其次，构建工具的「无感化」趋势会更明显。现在的 Rspack 还需要你手动替换配置文件，未来的构建工具可能会内嵌到框架之中，你甚至不需要知道底层用的是哪个打包器。就像你在 Next.js 15+ 中不需要关心 Turbopack 的存在一样，你只需要 npm run dev，剩下的事情工具帮你搞定。

最后，我猜增量编译和缓存策略会成为构建工具的标配能力。不管是 Rspack 的持久化缓存、Turbopack 的函数级缓存，还是 Nx 和 Turborepo 的任务编排，所有的工具都在往同一个方向努力：只重建发生变化的部分。未来有一天，「完整构建」这个概念可能会消失，因为每次构建都自动是增量的。

对于还在用 Webpack 团队，我的建议是：不要等到项目大到不敢迁移的时候才动手。趁现在项目规模还在可控范围内，花一两天时间评估 Rspack，如果你感受到了 12 倍的构建速度提升，你会感谢你自己做出了这个决定。

📝 写在最后：工具是手段，效率是目的#

这篇文章从 Rspack 和 Turbopack 的对比开始，聊到了 Rust 在前端工具链中的崛起。但说到底，不管用什么构建工具，我们的最终目的都是提升开发效率、改善开发者体验。Webpack 在它的时代是伟大的工具，它开创了前端模块化的时代。但技术在进步，需求在变化，我们在有了更好的选择时就不应该固守在过去的舒适区里。

回想一下十年前的前端开发，我们用手动拼接脚本文件、用 Grunt 和 Gulp 做任务自动化、用 RequireJS 做模块加载。当时的开发者可能也觉得「够用了」，但正是因为有人不断追求更快更好的工具，才有了今天这个繁荣的前端生态。Rspack 和 Turbopack 的出现，就是这种不断追求更好的精神的体现。

所以我的建议很简单：打开你项目的终端，看看一次构建需要多久。如果超过十秒，就说明你的开发体验还有优化的空间。花一天时间试试 Rspack，你有很大概率获得立竿见影的体验提升。而如果你听说过 Rust 重写前端工具的趋势但一直没行动，那么今天就是最好的开始时机。

希望这篇文章能给你一些启发，也欢迎在评论区分享你的构建工具迁移经验或踩坑经历。大家一起交流，一起进步。

🌈 Rust 前端工具链生态全景：盘点 2026 年最值得关注的 Rust 前端项目#

最后我想盘点一下除了 Rspack 和 Turbopack 之外，2026 年还有哪些值得关注的 Rust 前端工具。因为 Rust 在前端工具链中的应用远不止打包这一个领域，它几乎在每一个环节都出现了让 JavaScript 实现望尘莫及的替代品。

第一个是 Biome，这是 Rust 实现的前端工具链统一方案，集成了代码格式化、代码检查、文件转换等功能，目标是替代 ESLint 和 Prettier 的组合。Biome 在 2026 年已经发布了 v2.0，性能比 ESLint + Prettier 的组合快了 20 倍以上，同时配置项更加简洁。最让我惊喜的是它的自动修复能力——检查出的问题大多数都能自动修复，不需要开发者手动改。

第二个是 Lightning CSS，Rust 实现的 CSS 解析器、转换器和压缩器。它完全兼容 PostCSS 的功能——自动添加浏览器前缀、CSS 嵌套、自定义媒体查询等——但速度快了 100 倍以上。在大型项目中，CSS 处理往往是构建过程中的一个瓶颈，Lightning CSS 把这个瓶颈彻底打破了。

第三个是 Oxc（Oxidation Compiler），正在用 Rust 重写 JavaScript/TypeScript 的编译工具链。它的 Parser（解析器）目前已经是 JavaScript 生态中最快的，比 Babel 的解析速度快了约 5 倍。Oxc 的目标是最终取代 Babel 和 TypeScript 编译器，提供一体化的编译方案。

第四个是 Parcel v3，虽然 Parcel 本身不是 Rust 写的，但它的底层核心（@parcel/source-map、swc 等）大量使用了 Rust。Parcel v3 以「零配置、纯 Rust 核心」为口号，在 2026 年获得了不少关注，尤其适合那些不想折腾 Webpack 配置的小型项目。

总结来说，2026 年的前端工具链正在经历一场由 Rust 驱动的静默革命。Rspack 和 Turbopack 只是这场革命中最显眼的部分，但真正的大趋势是：所有与「性能」相关的底层工具，都在从 JavaScript 迁移到 Rust。这是过去五年前端生态中最深刻的变革之一。如果你还没关注这个趋势，现在就是最好的时机。

从我个人多年的前端开发经验来看，这种底层工具被重写的趋势不仅不会停止，反而会加速。因为前端应用越来越复杂，构建的瓶颈越来越明显，而开发者对体验的要求也越来越高。我们无法接受一个一次构建需要三分钟的开发环境，就像我们无法接受一个需要十秒才能响应的应用一样。Rust 正好提供了解决这些瓶颈所需要的能力——极致的性能、安全的内存管理、无需 GC 暂停的确定性执行。所以我认为，Rust 在前端工具链中的地位只会越来越重要。