WHAT - SWC Rust-based platform for the Web

文章目录

[一、SWC 到底是什么？](#一、SWC 到底是什么？)
[二、为什么 SWC 会流行](#二、为什么 SWC 会流行)
[三、SWC 使用](#三、SWC 使用)
- Next.js
- Vite
- Turbopack
[四、SWC 和 Babel 的本质区别](#四、SWC 和 Babel 的本质区别)
[五、SWC 在构建体系中的位置](#五、SWC 在构建体系中的位置)
[六、从架构视角看 SWC 的意义](#六、从架构视角看 SWC 的意义)
[七、作为前端工程师该怎么理解 SWC](#七、作为前端工程师该怎么理解 SWC)
[八、什么时候选 SWC](#八、什么时候选 SWC)
- 项目规模是否足够大
- [是否需要大量 Babel 插件生态](#是否需要大量 Babel 插件生态)
- [CI 构建时间是否成为成本](#CI 构建时间是否成为成本)
九、更深层认知

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 转译器"

例如：

bash 复制代码

vite-plugin-swc

或：

bash 复制代码

@swc/core

用于替代 Babel。

八、什么时候选 SWC

项目规模是否足够大

小项目没必要。

是否需要大量 Babel 插件生态

如果高度依赖 Babel 插件，SWC 可能不够成熟。

CI 构建时间是否成为成本

如果构建 5 分钟以上，就值得考虑。

九、更深层认知

SWC 不只是"快"。它代表的是：

前端正在进入"工程化性能时代"

了解更多：

SWC 的内部原理（AST 处理流程）
SWC vs esbuild 深度对比
SWC 在 Vite 里的具体工作方式