WHAT - SWC Rust-based platform for the Web
文章目录
- 一、SWC 到底是什么？
- 二、为什么 SWC 会流行
- 三、SWC 使用
- 四、SWC 和 Babel 的本质区别
- 五、SWC 在构建体系中的位置
- 六、从架构视角看 SWC 的意义
- 七、作为前端工程师该怎么理解 SWC
- 八、什么时候选 SWC
- 九、更深层认知
SWC 是一个 用 Rust 写的 JavaScript / TypeScript 编译器工具链，目标是：
替代 Babel，并且比它快 10~20 倍
它是现代前端构建体系里非常核心的一环。
一、SWC 到底是什么？
官方定位是：
Rust-based platform for the Web
拆开讲就是：
- Rust 写的
- 面向 Web 构建
- 提供编译、转译、压缩等能力
核心能力包括：
- TS → JS 转译
- JSX → JS
- ESNext → ES5
- 代码压缩（minify）
- Tree shaking
- 插件系统
二、为什么 SWC 会流行
因为一个现实问题：
Babel 太慢了
Babel 是 JS 写的，本质是 AST 解析 + 转换。
当项目变大：
- 几千个模块
- 大量 TS
- 大量 JSX
编译时间会指数级变慢。
而 SWC 用 Rust：
- 多线程
- 原生执行
- 零 GC 开销
- 内存更可控
在真实项目里：
- Babel 构建 60 秒
- SWC 可能 5~8 秒
三、SWC 使用
Next.js
Next.js 12 之后默认用 SWC 替代 Babel。
Vite
Vite 内部依赖 esbuild（也是 Go 写的），但很多生态已经开始支持 SWC 插件。
Turbopack
Turbopack 是 Vercel 做的新一代打包器，底层也是 Rust + SWC 体系。
四、SWC 和 Babel 的本质区别
| 维度 | Babel | SWC |
|---|---|---|
| 语言 | JavaScript | Rust |
| 执行方式 | 单线程 | 多线程 |
| 性能 | 慢 | 极快 |
| 插件生态 | 成熟 | 逐渐完善 |
| 适合 | 灵活定制 | 高性能场景 |
五、SWC 在构建体系中的位置
现代前端构建大概分三层：
1. 代码转换（Compiler） - Babel - SWC - esbuild 2. 模块打包（Bundler） - Webpack - Vite - Turbopack 3. 运行时优化 - Tree shaking - Code splitting - Minify SWC 是第一层：编译器
六、从架构视角看 SWC 的意义
SWC 的出现其实是一个趋势信号：
前端工具链正在从 JS 迁移到系统语言（Rust / Go）
为什么？
因为：
- 项目规模爆炸
- TS 类型越来越复杂
- CI 时间成本巨大
- 构建性能成为瓶颈
所以你看到：
- SWC（Rust）
- esbuild（Go）
- Turbopack（Rust）
- Rome（Rust）
- Biome（Rust）
七、作为前端工程师该怎么理解 SWC
如果你现在是 Vite + React + TS 项目，你可以理解为：
SWC 是一种“更快的 TS 转译器”
例如：
vite-plugin-swc 或：
@swc/core 用于替代 Babel。
八、什么时候选 SWC
项目规模是否足够大
小项目没必要。
是否需要大量 Babel 插件生态
如果高度依赖 Babel 插件，SWC 可能不够成熟。
CI 构建时间是否成为成本
如果构建 5 分钟以上，就值得考虑。
九、更深层认知
SWC 不只是“快”。它代表的是：
前端正在进入“工程化性能时代”
了解更多：
- SWC 的内部原理（AST 处理流程）
- SWC vs esbuild 深度对比
- SWC 在 Vite 里的具体工作方式