你有没有发现，最近两年前端圈有一股很明显的「锈化」浪潮——
Babel 慢，有人用 Rust 写了个 SWC 替掉它；Webpack 配置烦、构建慢，字节用 Rust 撸了个 Rspack；Next.js 干脆把打包器换成 Rust 写的 Turbopack；连 ESLint + Prettier 都被 Rust 的 Biome 一锅端了。
这不是个别团队的炫技。这是一次系统性的工具链迁移：前端基建正在从「Node.js 包」变成「原生二进制」。
这篇文章聊清楚三件事：为什么是 Rust、到底有哪些东西被重写了、以及这事对你写业务代码到底意味着什么。
为什么是 Rust，不是 Go、也不是继续用 JS
先说结论：Rust 在这一波里赢，靠的不是「快」这个单一维度，而是快 + 内存安全 + 零成本抽象 + 天然适合并行的组合。
前端工具链的几个典型负载——解析、转译、打包、压缩——有个共同特征：计算密集、数据局部性差、可以大量并行。这正是 Rust 的主场：
- 没有 GC 停顿。JS/Go 的垃圾回收会在构建中途突然卡一下，Rust 编译期就解决了所有权，运行期没有这种抖动。
- 能放心并行。Babel 之所以慢，很大程度是因为它的 AST 遍历是单线程的；Rust 的
rayon让你「par_iter()一行」就把文件级任务铺到所有核上。 - 零成本抽象。高阶封装编译后和手写循环一样快，所以工具作者敢把 API 写优雅而不用担心性能税。
那为什么不是 Go？Go 也有并发，但 GC 和值语义（Go 默认传引用、切片隐式共享）在前端工具这类「大量小对象 + 频繁分配」的场景里，体感不如 Rust 干净。esbuild 用 Go 已经很快了，但后续这批「全栈 Rust」玩家选了 Rust，趋势很清楚。
一句人话总结：Rust 让工具作者既能写出安全的底层代码，又能榨干多核，还不用在运行时养一个垃圾回收器。
盘点：那些已经被 Rust 化的前端基建
下面这些是已经能「在生产里直接替换」的，不是 demo。
1. SWC —— 替掉 Babel 的转译器
SWC（Speedy Web Compiler）是最早出圈的一个。它用 Rust 重写了 Babel 的活：把 TS/JSX/ESNext 转成目标版本 JS。
// 老路子：.babelrc
{ "presets": ["@babel/preset-env", "@babel/preset-typescript"] }
// 新路子：.swcrc（配置长得几乎一样，但快 10~20 倍）
{
"jsc": { "parser": { "syntax": "typescript", "tsx": true } },
"module": { "type": "es6" }
}
Next.js 从某版本起默认用 SWC 做转译，Vite 也在用 SWC 做部分转换。你没改任何代码，构建就莫名其妙快了一截——背后就是它。
2. Rspack —— 字节出的 Webpack 替代品
Webpack 的生态最完整，但「构建五分钟、改一行等半天」的 HMR 体验被吐槽了十年。Rspack 用 Rust 重写，但刻意兼容 Webpack 的 loader / plugin 配置，让存量项目能低成本的迁移。
// 配置几乎照搬 webpack.config.js，把包名换掉即可
const { rspack } = require('@rspack/core');
module.exports = {
entry: './src/index.js',
builtins: { react: { runtime: 'automatic' } }, // 内置 SWC 做 JSX 转换
};
对「Webpack 重度用户」来说这是目前最顺滑的提速方案，不用把构建系统推倒重来。
3. Turbopack —— Next.js 的官方继任打包器
Vercel 用 Rust + Lightning CSS 写的 Turbopack，主打增量构建：只重新编译你真正改动的那个文件及其依赖闭包。本地 dev 起一个超大仓库，冷启动和 HMR 都比 Webpack 时代轻得多。它现在已经是 Next.js 的默认打包器（dev 模式）。
4. Rolldown —— Rollup 的 Rust 移植，Vite 的下一代内核
这个最值得前端人关注。Vite 现在 dev 用 esbuild、build 用 Rollup，两套内核有割裂。Rolldown 是「用 Rust 重写 Rollup」，API 和插件生态对齐 Rollup，但速度看齐原生。Vite 已经官宣后续用 Rolldown 统一 dev/build。
也就是说：不久的将来，你写 vite.config.ts 时，底下其实跑着 Rust。
5. Biome —— 一个二进制干掉 ESLint + Prettier
Biome（前身 Rome）用 Rust 重写，把 lint + format 合并成一个工具，统一用 biome.json 配置，启动和修复都是毫秒级。
{
"linter": { "enabled": true, "rules": { "recommended": true } },
"formatter": { "enabled": true, "indentStyle": "space" }
}
npx @biomejs/biome check --write src/ # 一条命令：格式化 + 修 lint
省掉的不仅是时间，还有「ESLint 和 Prettier 打架」的那堆配置。
6. oxc —— 藏在底下的「工具链底座」
oxc（Oxide）是更底层的一件事：它提供解析器、linter、转换器、压缩器的一套 Rust 原生模块，目标是成为所有上层工具的公共底座。SWC、Biome、Rolldown 们解决了单点，oxc 想解决「重复造轮子」——让大家共用同一个最快的 Parser。Vite、Vitest 已经在引入 oxc。
7. 顺带提一嘴：Deno / Lightning CSS
- Deno 运行时本身就是 Rust 写的，跑 TS 不用编译步骤。
- Lightning CSS 用 Rust 重写 CSS 工具链（压缩、嵌套、厂商前缀），Turbopack 直接用它。
架构层面的真变化：插件模型变了
很多人只盯着「快了多少倍」，但更深的改变是插件从 JS 函数变成原生扩展。
Webpack 的插件是 JS 闭包，跑在 Node 里；Rspack 为了兼容才保留了 JS 插件桥。但新一代工具（oxc、Turbopack）的趋势是：核心逻辑在 Rust 里，插件要么用 Rust 写、要么通过 napi 调用 Node。这让「写个自定义 loader」的门槛变了——你得更懂 FFI，但换来的收益是插件不会再成为性能瓶颈。
对业务开发者来说，短期的直观感受是：你大概率不用自己写这些插件，工具链已经把常用能力内置了（Rspack 的 builtins、Biome 的 recommended 都是这个思路）。
代价：Rust 化不是免费午餐
说点实在的取舍，免得你觉得「全换 Rust 就完了」：
- 二进制分发与 wasm。本地 CLI 是原生二进制没问题；但要在浏览器里跑（比如在线 playground、CDN 边缘），得编译成 wasm，体积和启动成本要重新算。
- 生态成熟度。Rollup 那套插件沉淀了十年，Rolldown 还在对齐；某些冷门 loader 可能暂时没有 Rust 版，迁移时得评估覆盖度。
- 调试心智。报错栈从 JS 变成 Rust panic / napi 边界，前端同学排错要适应一层。
- 锁定风险。工具链收敛到少数几个 Rust 项目（oxc / Rolldown / Biome），一旦某个出问题，影响面比过去「百花齐放」更大。
我的判断：对 90% 的业务项目，直接跟着框架默认走就行——用 Next.js 就享受 Turbopack，用 Vite 就等 Rolldown，用 Rspack 就顺着迁移。别为了「用 Rust 工具」去折腾构建系统，性价比低。
对你写业务代码意味着什么
一句话：你大概率感觉不到 Rust，但会持续感到「构建变快了」。
这波迁移最大的价值不是让你学 Rust，而是把「等构建」这段死时间一点点抠掉。dev 启动从 30 秒变 3 秒、CI 从 10 分钟变 2 分钟，累积下来是实打实的心流和算力成本。
作为前端，值得做的是：
- 关注你框架默认构建器的演进（Next → Turbopack、Vite → Rolldown），升级时别抗拒；
- 把 lint/format 统一到 Biome 这类一体化工具，少养一套配置；
- 真要做构建定制时，先看看是不是官方
builtins已经内置了。
锈化不是潮，是前端基建被「性能债」逼出来的自然进化。工具越来越快、越来越省心，剩下的创造性工作，才真正该留给写代码的你。
参考资料：SWC / Rspack / Turbopack / Rolldown / Biome / oxc 官方文档与发布公告。
