TypeScript + SWC：Rust 速度的现代编译方案
SWC 是 Rust 编写的 TS/JS 编译器，负责语法转换，不承担 tsc 的完整类型检查，已成为 Next.js 的默认编译器。本文讲解 SWC 配置 TypeScript 编译、两种编译模式、watch 模式与测试集成。
SWC 用 Rust 重写了 TypeScript 编译链路：npm i -D @swc/cli @swc/core，一个 .swcrc 配置文件即可替代 Babel/tsc 的转译工作，编译速度提升一个数量级。注意 SWC 只做转译不做类型检查——tsc --noEmit 仍需保留在 CI 中。
SWC 为什么这么快
单线程的 Babel/tsc 用 JavaScript 处理 JavaScript，SWC 用 Rust 并充分利用多核并行。冷启动与增量编译的差距在大型项目上尤为明显：秒级变毫秒级。Next.js、Turbopack、Rspack 选择 SWC 作为默认编译器，就是市场对速度的投票。
安装与配置
npm install --save-dev @swc/cli @swc/core
.swcrc：
{
"jsc": {
"parser": { "syntax": "typescript", "tsx": false },
"target": "es2022",
"transform": {}
},
"module": { "type": "commonjs" },
"sourceMaps": true
}
npx swc src -d dist # 编译 src 到 dist
两种编译模式的取舍
- 转译模式（默认）：剥离类型、转换语法到目标 ES 版本——快，但不检查类型错误；
- 类型检查模式：SWC 不做全量类型检查，这是它与 tsc 的本质分工。类型安全靠编辑器 + CI 里的
tsc --noEmit兜底，转译交给 SWC——各司其职。
Watch 模式与开发体验
npx swc src -d dist --watch
配合 nodemon（nodemon dist/index.js）获得"保存即重启"的开发循环。由于 SWC 足够快，这个循环的延迟几乎无感——和 tsx 这类运行时方案的体验相当。
测试集成：SWC + Vitest
@swc/jest 是 Jest 转换器，不能直接当作 Vitest 插件。下面仅演示 Jest 迁移：Jest 项目把 transform 从 babel-jest/ts-jest 换成 @swc/jest，需检查转换语义、装饰器与 sourcemap，并独立运行 tsc 检查类型：
// jest.config.js
module.exports = {
transform: { '^.+\\.(t|j)sx?$': '@swc/jest' },
};
常见问题（FAQ）
Q：SWC 能完全替代 tsc 吗？
转译可以，类型检查不行。工作流变成：开发期编辑器即时类型提示 + SWC 秒级编译；CI 里 tsc --noEmit 做完整类型把关。
Q：SWC 和 esbuild 怎么选？
esbuild 定位打包器（bundler），SWC 定位编译器（可插拔 transformer）。Next.js 用 SWC、Vite 用 esbuild——跟框架走通常没错；自建工具链时两者都可用 SWC 的插件生态（装饰器、React 转换）更丰富。
Q：生产部署 SWC 编译产物还是运行时方案（tsx）？
生产推荐预编译（SWC 产物）：无运行时转译开销、可配合多阶段 Docker 构建减镜像。tsx 适合开发期与脚本。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
