SWC 替代方案盘点：6 大 TS 编译工具
SWC 之外的选择：esbuild、tsc、Bun、Vite、Babel、tsx 各有擅长。本文按场景盘点 6 大替代方案。
按场景选：生产类型检查必须用 tsc；打包构建选 esbuild/Vite；运行时执行选 tsx/Bun；需要深度 AST 插件选 Babel。SWC 的强项是"框架内置编译器"（Next.js/Rspack）——独立使用的场景这些替代往往更顺手。
本文涉及 Vite 架构时，以版本区分：Vite 7 及更早版本使用 esbuild／Rollup 的组合；Vite 8 已改用 Rolldown 与 Oxc。旧插件及构建选项迁移请按 Vite 8 迁移文档 检查，不能将旧版本的内部实现当作当前所有版本的行为。
SWC 的边界
Rust 速度无敌，但：插件生态年轻（Wasm 插件体系）、纯转译不做类型检查、独立使用时的工具链集成度不如专项工具。
1. esbuild：打包场景的王者
Go 实现，打包+压缩一体，Vite/tsx 的底层。需要"转译+打包"一步完成时 esbuild 比 SWC 更直接。
2. tsc：类型检查的唯一权威
任何方案都不替代 tsc --noEmit 的类型把关。小项目甚至可以直接 tsc 转译（牺牲速度换零依赖）。
3. Bun：运行时一体化
bun build + bun run——转译只是 Bun 四合一工具链的一环。全 Bun 工作流中无需单独选编译器。
4. Vite：前端构建的事实标准
前端项目的构建答案（esbuild 开发 + Rollup 生产）。SWC 可通过插件接入 Vite，但默认配置已足够好。
5. Babel：插件生态的活化石
需要成熟 AST 插件（特定语法转换、老项目兼容链）时 Babel 仍是唯一答案。新项目不主动选，存量不急着换。
6. tsx：开发期执行
"跑 TS"而非"编译 TS"——tsx 开发体验最优（esbuild 内核）。生产用编译产物，开发用 tsx。
速查表
| 需求 | 工具 |
|---|---|
| 类型检查 | tsc（唯一） |
| 库/应用打包 | esbuild / Vite |
| 开发跑 TS | tsx / Bun |
| 深度语法插件 | Babel |
| Next.js/Rspack 内置 | SWC（不用选） |
常见问题（FAQ）
Q：SWC 和 esbuild 性能差多少？
同数量级（都比 tsc/Babel 快一个数量级以上）。两者间的选择看功能（SWC 插件变形能力强，esbuild 打包完整）而非速度。
Q：能混用吗？
本来就该混用：开发 tsx、构建 SWC/esbuild、检查 tsc——各管一段，这是现代 TS 工具链的标准形态。
Q：tsdown/Rolldown 之类新工具呢？
Rolldown（Rust 版 Rollup，Vite 的未来引擎）值得关注——工具链的 Rust 化是进行时，评估窗口每年都在更新。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
