大约一年半前，我在一个维护了三年多的中大型前端工程里，第一次把“WHAT”这个标题当成一个正式问题问出了口：这套用Rust重写Web编译链路的SWC平台，到底强在哪、弱在哪、哪些项目适合切、哪些项目切了就是给自己挖坑？
项目切换后的数据很直观：冷启动构建时间从90秒左右掉到了17秒左右，热更新响应从原先偶尔要等两秒钟变成基本感觉不到等待。但真正让我决定写这篇复盘的原因不是这些分，而是接入过程中踩过的那几个文档没有写透的坑。如果你正打算把Babel从工程里请出去，或者你只是听说过SWC但搞不清楚它和webpack、Vite、Terser之间的关系，这篇文章应该能帮你省下不少试错时间。
1. 先搞清楚：SWC在Web工具链里的生态位
1.1 它不是一个打包器，但它确实能打包
很多人第一次看到SWC的介绍，会下意识把它归类成webpack的替代品。这是最容易产生的误解。SWC全称Speedy Web Compiler，核心身份是编译器，不是打包器。它负责把你写的TypeScript、JSX、ES2023这些现代代码，转换成浏览器和目标运行时能直接跑的ES5或ES6代码，顺带做压缩和某些代码优化。
但SWC确实也提供了一个打包模式，通过spack命令行工具或@swc/core里的API来使用。这个打包模式和webpack最大的区别在于：webpack生态里有大量的loader和plugin来处理各种静态资源、样式、代码分割、运行时注入，而SWC的打包器只专注于JavaScript/TypeScript层面的合并和组织。CSS、图片、字体这些资源如果想让SWC打包器一并处理，基本是做不到的，要么交给webpack，要么就要搭配其他工具。
我当时的结论很简单：SWC的打包模式只适合非常轻量、没有复杂静态资源依赖的库项目或小服务，不适合拿来替换webpack做应用级打包。真正稳妥的路线是用SWC替代Babel这一个环节，webpack继续干它最擅长的分包、资源处理和插件编排。
1.2 它和Babel、TypeScript编译器之间是什么关系
先讲一个常见的场景。一个React项目通常要经历这些转换：TS语法转成JS、JSX转成createElement调用、新版ES语法降级到目标浏览器支持的旧语法、然后再根据项目需要插入各种Babel插件做额外处理。
Babel做的是后面三件事里的很大一部分，TypeScript编译器tsc负责的是类型检查和TS语法剥离。这两个工具链条叠加，性能开销就上来了，尤其是大型项目里，每次保存文件都要跑一遍，慢是必然的。
SWC吸收了两类工具的职责：它能解析TS语法并剥离类型，也能做ES语法降级和JSX转换，同时还内置代码压缩能力。最实用的组合方式是用SWC做转译，再用tsc --noEmit单独做类型检查。这样类型检查频率可以自己控制，比如提交代码时或者CI里跑一次，不需要每次热更新都全量检查，开发时的整体响应速度会明显提升。
1.3 为什么Rust在这个位置是“正确答案”
聊SWC绕不开Rust。用Rust实现编译器的核心价值，体现在两个层面：第一是性能，Rust编译出来的原生代码在执行解析、AST遍历、代码生成这些密集计算任务时，比JavaScript写的Babel快一个数量级；第二是内存安全和并发能力，Rust的所有权模型让编译器在解析大量文件时，可以安全地利用多核并行，而不用担心数据竞争写出崩溃程序。
说人话就是：Babel是JavaScript写的，它在一个JavaScript运行时里处理JavaScript代码；SWC是Rust写的，它直接编译成机器码来处理JavaScript代码。相当于一个是请了一个在美国总部办公的远程支持团队，一个是把支持团队请到了你办公室里。两者都能解决问题，但响应延迟完全不是一个量级。
这也是为什么不少新一代前端工具都开始用Rust重写，除了SWC之外，esbuild、Turbopack，包括一些Lint工具都用到了Rust或Go这类更底层语言。Web工具链的语言层次正在悄悄换代，SWC是这股浪潮里相当稳当的一个代表。
2. 用之前必须弄懂的核心概念：转译、打包、压缩、类型检查
2.1 四个长得像但完全不是一回事的任务
动手配置前如果没搞清楚下面四个概念，后面配置SWC时一定会乱：
- 转译（Transpile）：把源代码从一种语言级别转换成另一种，比如TS转JS、JSX转普通JS、ES2023转ES2017。
- 打包（Bundle）：把多个分散的模块文件合并成少数几个可部署文件，核心是解决模块依赖关系、作用域隔离、代码分割。
- 压缩（Minify）：把代码里的空白、注释、长变量名去掉，让文件体积更小，加载更快。
- 类型检查（Type Check）：基于类型系统做静态分析，在运行前找出类型不匹配问题。
Babel只负责转译，webpack主要负责打包，Terser专门做压缩，tsc做类型检查。这一套组合拳每个环节独立、互相配合。SWC的野心在于把转译和压缩这两块吃掉，而且吃得又快又好，但打包和类型检查这两件事它没有完全替代。
2.2 SWC在实际工程中承担的部分
我把我们项目的处理链路画在一张脑子里，大概是这样的：
src目录（TS/JSX） ↓ SWC转译（TS语法剥离、JSX转换、ES语法降级） ↓ webpack接管（模块解析、依赖收集、代码分割、静态资源处理） ↓ SWC压缩（可选，替代Terser） ↓ dist目录（浏览器可用的JS文件）在这个链路里，SWC同时干了原先Babel和Terser两份活。类型检查单独保留给tsc，在CI阶段跑一次，不再阻塞开发时的每次构建。
2.3 与webpack协作时的Loader逻辑
SWC要和webpack配合，是通过swc-loader这个桥接模块实现的。它的作用和babel-loader完全对应：webpack在解析到.ts或.tsx文件时，会把文件内容交给swc-loader处理，SWC完成转译后再把标准JavaScript返回给webpack继续打包。
配置层面最关键的一点是：SWC的配置项和Babel完全不一样，不要想着把.babelrc里的plugins直接抄到.swcrc里。SWC有自己的配置结构，比如JSX转换、TypeScript解析、目标环境、压缩参数都是在jsc这个字段下组织的。我见过不少人在这里栽了跟头，配置文件报错报得莫名其妙，其实就是把两套东西混在一起了。
3. 从零接入：一套可复现的替换Babel完整路线
3.1 安装依赖，版本锁定很重要
这一步看起来没什么技术含量，但恰恰是我当时浪费了大半天的地方。如果你用的是webpack 5，swc-loader版本和@swc/core版本必须匹配，@swc/core的版本差异还会影响AST输出结果，导致一些Edge-case语法在低版本下报错。
推荐的做法是把核心依赖版本用精确锁定的方式装在package.json里，而不是用^号：
{ "devDependencies": { "@swc/core": "1.6.7", "@swc/helpers": "0.5.12", "swc-loader": "0.2.6" } }其中@swc/helpers是容易被忽略的一个包。SWC在转译源代码时，会注入一些运行时辅助函数，比如_class_call_check、_define_property这些，如果不显式安装@swc/helpers，SWC就会默认把辅助代码内联到每个文件里，结果就是产物体积变大，而且还可能在多个模块之间产生重复代码。
3.2 基础配置文件示例
在项目根目录创建一个.swcrc文件，下面这份配置是我自用后验证过的，适用于React+TypeScript的webpack项目：
{ "jsc": { "parser": { "syntax": "typescript", "tsx": true, "decorators": false, "dynamicImport": true }, "transform": { "react": { "runtime": "automatic", "development": false, "refresh": true }, "legacyDecorator": false, "decoratorMetadata": false }, "target": "es2017", "loose": false, "externalHelpers": true, "minify": false }, "minify": false, "module": { "type": "es6" } }几个关键项拆开说：
externalHelpers: true表示运行时辅助函数从@swc/helpers引入，而不是内联，这就是上面提到控制产物体积的手段。runtime: "automatic"是React 17以后推荐的JSX转换方式，不需要手动import React，SWC会自动引入jsx-runtime，和官方新版React的编译逻辑保持一致。module.type: "es6"表示保留ES Module语法，不要转成CommonJS。这个交给webpack处理就行，因为webpack对ESM的Tree Shaking效果更好，产物更干净。
webpack侧配置swc-loader的部分：
// webpack.config.js module.exports = { module: { rules: [ { test: /\.[jt]sx?$/, exclude: /node_modules/, use: { loader: 'swc-loader', options: { // 这里可以放运行时覆盖配置 } } } ] } // 其余配置保持不变 };3.3 性能验证与回滚方案
接完之后不要只看构建成功就算完事。我建议做三个维度的验证：
- 构建时间对比：同样的代码和机器，Babel和SWC各跑5次，取中位数。跑下来如果提升幅度没有达到自己预期，先查一下是不是整个构建链路里还有其他瓶颈。
- 产物对比：用Babel构建一次，用SWC构建一次，对比产物在目标浏览器里的运行行为是否一致。重点检查class特性、async/await降级、生成器函数这几个容易出问题的地方。
- 回滚开关：在package.json里保留Babel相关依赖，别急着删干净。上线稳定运行两周后再清理，给自己留一条后路。
回滚方案这件事看起来啰嗦，但它决定了你在团队里推进这个技术切换的底气。项目出问题的时候，能快速回到之前的状态，比你拍胸脯保证“这方案不会出问题”有效得多。
4. 开发体验：热更新、缓存与SWC插件的真实表现
4.1 为什么热更新变快了
热更新速度取决于两个阶段：文件变更后的重新转译速度，以及模块依赖图的diff速度。webpack 5的持久化缓存已经优化了依赖图的diff，但转译这个环节如果还是Babel，它就是你整个链路里最慢的一环。换成SWC后，文件从读取到转译完成的时间几乎可以忽略不计，热更新体感上的延迟绝大部分转移到了webpack的模块刷新和浏览器端重渲染上。
在macOS上一台老款M1芯片机器上，我实测了一个包含1700多个文件的React项目：保存一个修改过的组件文件后，SWC热更新总耗时约180ms，之前Babel方案里这个数字是1.2秒到2秒。这个差距在频繁改动样式和调试组件时非常明显，几乎不再有“改一行代码等半天才看到效果”的烦躁感。
4.2 SWC的自带插件体系与边界
SWC从早期开始就支持插件机制，用Rust写的原生插件可以做到在转译过程中对AST做自定义操作，相当于Babel plugin的Rust版本。还有一个@swc/plugin-transform-imports之类的官方插件，可以帮你做类似babel-plugin-import那样的按需引入优化。
但这里要提醒一句：SWC的插件生态成熟度目前还是赶不上Babel。如果你项目里的Babel插件是自己用JavaScript写的，而且做了相当深度的AST操作，比如特殊的装饰器处理、自定义语法糖转换，那么迁移到SWC时的改造成本要高很多。简单的、被高频使用的插件，SWC生态里基本都有对应解决方案；冷门的、项目定制的Babel插件，大概率需要硬着头皮改或者是找替代方案。
我的建议是分步走：第一步只替换转译核心流程，第二步再看插件兼容。不要试图一天之内把所有Babel插件都迁到SWC里，那会让你陷入一个巨大的兼容性泥潭。
5. 踩过的坑：三件文档没写透的事
5.1 版本不匹配导致的“幽灵行为”
这是我最想拿出来讲的一个坑。某次升级@swc/core从1.5.x到1.6.x之后，构建没有报任何错误，但线上产物出现了一个奇怪的运行时报错，涉及一个异步函数内部的for...of循环。在本地Chrome和Node环境里复现不出来，只有在部分低版本浏览器里才触发。
最后排查下来，问题出在SWC版本变动后对for...of的目标环境判断发生了变化，生成了不带Symbol.iterator兼容垫片的代码。这类问题非常隐蔽，因为你完全看不到编译错误，只有跑到特定运行环境才炸。解决方案就是锁定精确版本，升级时先看changelog里关于目标降级和helper函数的部分，升完级之后用低版本浏览器或无头浏览器跑一遍集成测试。
5.2 代码分割与动态导入的时序问题
SWC转译动态导入（dynamic import）时，如果配置里把module.type设成了commonjs，它会把import()转成Promise.resolve().then(() => require(...))这种形式，这在webpack里会导致代码分割失效，所有通过动态导入的模块都会被合并进主包，单页应用的初始加载体积直接变大。
这也是为什么我在前面那份配置里强调module.type要保持es6。这个参数本身就是和webpack打配合的，如果设成CommonJS，你就等于亲手废掉了webpack的代码分割能力。排查方法很简单：构建完成后先看产物里有没有按路由拆开的独立chunk文件，没有的话优先检查这个配置项。
5.3 styled-components等Babel插件的迁移困境
styled-components在Babel环境下有官方插件babel-plugin-styled-components，它的作用是给生成的样式类名加上调试用的组件名，同时做SSR场景下的样式收集。这个插件在SWC生态里也有对应的@swc/plugin-styled-components，但版本支持存在滞后性。
我们项目当时试过切到SWC插件版，结果是样式能正常生成，但组件名在React DevTools里丢失了，部分SSR样式收集也出现了少量重复样式。最后权衡下来，保留了一个窄通道：只有SSR渲染入口那段代码继续用Babel处理，其余业务代码走SWC。这种“混跑”方案听起来不够优雅，但在实际项目中能同时保住编译性能和生产正确性，性价比很高。
这个思路也值得你参考：不要执着于“全有或全无”的切换。混跑方案只要链路设计清楚，性能提升照样能吃到大部分。
- 新旧工具混跑时，入口边界要清晰
- 构建产物体积和CSS收集结果要进行对比测试
- 使用styled-components等项目时，提前检索SWC插件支持状况
6. 哪些项目暂时不适合切到SWC
6.1 深度定制Babel插件的老项目
如果一个项目的构建流程重度依赖自己写的、或者依赖很冷门的Babel插件，SWC的迁移成本可能大于收益。比如项目里用了babel-plugin-macros或者自定义的AST修改规则，在SWC里很可能没有现成对应物。
在做技术选型时，不应该只盯着转译速度这一个指标。工具链本质上是团队开发流程的一部分，迁移的时间成本也是成本。如果全组只有你一个人了解Rust和SWC插件机制，后续维护的责任也会落在你一个人身上，这个隐性压力在技术选型时也应该考虑进去。
6.2 类型检查不能被错误省略
前面提到过用tsc --noEmit做类型检查，但有些团队会觉得SWC能处理TS语法，那是不是就可以不装TypeScript编译器了？这是一个危险的误解。SWC剥离TS类型完全不检查类型，它只做透传和剥离，类型错误在被SWC转译时根本不会被发现。
我当时在CI脚本里保留了一条独立的类型检查任务：
{ "scripts": { "build": "tsc --noEmit && webpack --mode production", "dev": "webpack serve" } }开发时为了速度可以不跑tsc，但发布构建前必须跑。这个体验上的取舍是合理的，因为开发时的反馈速度和生产环境的代码安全都很重要，两者完全可以分开来管理。
6.3 当前SWC的短板与后续可能性
SWC也在不断迭代，项目里用到SWC当实际编译器的不只是Next.js，很多大型框架都把SWC作为JavaScript/TypeScript转译基础设施。下一阶段SWC的插件生态一定会更丰富，Rust原生插件和JavaScript侧工具的连通会做得更好。那些现在无法迁移的深度定制Babel插件，未来有可能找到对应的SWC替代品。
对于目前还在犹豫的团队，我的建议是在一个独立分支或者side project里先试验性接入SWC，跑通核心流程之后再做评估。不要在没有充分验证的情况下直接从Babel全部切换，也不要在遇到一个插件兼容问题时就全盘否定SWC。这个领域的变化速度比我刚接触它时快得多，每隔几个月回头看一眼生态进展，比一次性做长期预测要现实得多。
我在实际切换完之后有个体会：工具链优化里最值钱的部分，往往不是那点构建时间的绝对值，而是它给开发节奏带来的变化。当一次保存到页面刷新的等待时间从两秒降到几百毫秒，团队里所有人的调试心流都会变得更连贯。把Babel换成SWC不是目的，让开发过程更流畅才是。如果你也正在做类似的工具链切换，希望这篇复盘里面的路线和那些坑，能让你少走一些弯路。
