前端领域的新一代构建工具 SWC

SWC (Speedy Web Compiler) 详解

SWC 是一个用 Rust 编写的、速度极快的 JavaScript/TypeScript 编译器和平台。它的主要目标是提供比 Babel 等传统 JavaScript 工具链更优越的性能，同时保持与现有生态系统的兼容性。

1. SWC 是什么？为什么需要它？

• 定义： SWC (Speedy Web Compiler) 是一个基于 Rust 的超快速 TypeScript / JavaScript 编译器。它不仅仅是一个编译器，更像是一个可扩展的平台，可以用于编译、压缩、打包（实验性）、代码检查等。

• 核心优势： 速度。由于 Rust 提供了接近 C/C++ 的性能和内存安全保证，SWC 在执行代码转换、压缩等任务时，通常比用 JavaScript 编写的工具（如 Babel、Terser）快得多，在某些场景下甚至能达到 10-20 倍甚至更高的性能提升。

• 目标：

  1. 替换 Babel： 提供与 Babel 类似的代码转换功能（例如，将 ESNext 语法转换为 ES5），但速度更快。
  2. 替换 Terser/UglifyJS： 提供高性能的代码压缩功能。
  3. 实验性功能： 探索打包 (Bundling) 等其他构建工具链的功能。
  4. 可扩展性： 通过插件系统（主要是 Rust 插件，以及新兴的 WASM 插件支持）允许开发者自定义转换逻辑。

为什么需要 SWC？

随着前端项目规模的日益增大和复杂化，JavaScript 构建工具的性能瓶颈越来越突出。缓慢的构建和重新编译时间会严重影响开发效率和体验。SWC 的出现，正是为了解决这个痛点，通过利用 Rust 的高性能特性，大幅缩短构建时间。

2. SWC 的核心功能

• 编译 (Transpilation):

  • 将现代 JavaScript (ES2015, ES2016, ..., ESNext) 语法转换为向后兼容的版本 (如 ES5)。
  • 支持 TypeScript 的编译，移除类型注解并转换为 JavaScript。
  • 支持 JSX (React, Preact 等) 的转换。
  • 支持各种 ECMAScript 提案阶段的特性。

• 压缩 (Minification):

  • 移除不必要的字符（空格、注释）、缩短变量名、内联函数等，以减小代码体积。SWC 的压缩器旨在与 Terser 竞争。

• 打包 (Bundling - 实验性):

  • SWC 也在探索打包功能 (spack)，目标是成为一个快速的模块打包器，但目前仍处于实验阶段，功能和稳定性可能不如 Webpack、Rollup、Parcel 等成熟方案。

• Source Map 生成： 支持生成 Source Map，便于调试转换后的代码。

• 插件系统：

  • Rust 插件： 性能最高，但需要 Rust 知识。
  • WASM 插件 (WebAssembly)： 允许使用其他语言（理论上包括 JavaScript/TypeScript，编译到 WASM）编写插件，这是一个重要的发展方向，旨在降低插件开发的门槛，并提供沙箱化的安全执行环境。

3. 如何使用 SWC

SWC 主要通过以下几种方式使用：

3.1. 安装

首先，你需要安装 SWC 的核心包和命令行工具：

npm install --save-dev @swc/core @swc/cli
# 或者使用 yarn
# yarn add --dev @swc/core @swc/cli

• @swc/core: 提供了 SWC 的核心编译 API，供其他工具或脚本调用。
• @swc/cli: 提供了命令行界面，方便直接在终端中使用 SWC。

3.2. 命令行接口 (CLI) 使用

@swc/cli 提供了 swc 命令。

• 编译单个文件：

  npx swc ./src/input.js -o ./dist/output.js
  

  这会将 src/input.js 编译并输出到 dist/output.js。

• 编译整个目录：

  npx swc ./src -d ./dist
  

  这会将 src 目录下的所有 .js, .jsx, .ts, .tsx 文件编译到 dist 目录下，保持目录结构。

• 监听模式 (Watch Mode)：

  npx swc ./src -d ./dist -w
  

  当 src 目录下的文件发生变化时，自动重新编译。

• 指定配置文件：

  npx swc ./src -d ./dist --config-file .custom-swcrc
  

  默认情况下，SWC 会查找项目根目录下的 .swcrc 文件。

• 生成 Source Maps：

  npx swc ./src/input.js -o ./dist/output.js -s # 或者 --source-maps
  # 生成内联 source map
  npx swc ./src/input.js -o ./dist/output.js -s inline
  

• 压缩代码：

  npx swc ./src/input.js -o ./dist/output.min.js -C # 或者 --config minify=true
  # 也可以在 .swcrc 中配置
  

3.3. 配置文件 (.swcrc)

SWC 的行为可以通过一个 JSON 格式的配置文件 .swcrc 来控制。它通常放在项目的根目录下。

一个典型的 .swcrc 文件结构如下：

{
  "$schema": "https://json.schemastore.org/swcrc", // 可选，用于编辑器智能提示
  "jsc": { // JavaScript Compiler options
    "parser": { // 解析器选项
      "syntax": "ecmascript", // "ecmascript" 或 "typescript"
      "jsx": true, // 是否支持 JSX
      "dynamicImport": true, // 是否支持动态导入
      "privateMethod": true, // 是否支持私有方法
      "functionBind": false, // 是否支持 :: 操作符
      "exportDefaultFrom": true,
      "exportNamespaceFrom": true,
      "decorators": true, // 是否支持装饰器 (legacy)
      "decoratorsBeforeExport": true,
      "topLevelAwait": true,
      "importMeta": true
      // ... 更多 TypeScript 相关解析选项，如 "tsx": true, "dts": false
    },
    "transform": { // 转换选项
      "react": { // React/JSX 相关转换
        "runtime": "automatic", // "automatic" (React 17+) 或 "classic"
        "pragma": "React.createElement", // 经典模式下的 pragma
        "pragmaFrag": "React.Fragment", // 经典模式下的 Fragment pragma
        "throwIfNamespace": true,
        "development": false, // 是否为开发模式 (影响辅助函数和警告)
        "useBuiltins": true, // 是否使用内置的 React helper
        "refresh": false // 是否启用 React Fast Refresh (通常由框架插件控制)
      },
      "constModules": { // 将 const 枚举转换为对象字面量
        "globals": {
          // " CertainesConstantes": { "FOO": "bar" }
        }
      },
      "optimizer": { // 优化相关的转换
        "globals": { // 全局变量定义，用于 DCE (Dead Code Elimination)
          // "vars": { "__DEBUG__": "true" }
        },
        "jsonify": { // 将对象转换为 JSON 字符串
          "minCost": 1024
        }
      },
      "legacyDecorator": true, // 是否使用旧版装饰器提案
      "decoratorMetadata": false, // (与 TypeScript 的 emitDecoratorMetadata 类似)
      "regenerator": { // async/await 和生成器函数的转换
        "importPath": "@swc/helpers/lib/regenerator.js" // 默认为内联 regenerator runtime
      }
      // ... 还有很多其他转换器，如 "hidden": { "jest": true } 用于 Jest hoisting
    },
    "target": "es2016", // 目标 JavaScript 版本 (如 "es3", "es5", "es2015", ..., "es2022")
    "loose": false, // 是否启用宽松模式 (可能不完全符合规范，但代码更小/更快)
    "externalHelpers": false, // 是否将帮助函数从 @swc/helpers 导入，而不是内联
    "keepClassNames": false, // 是否保留类名 (用于调试或某些依赖类名的库)
    "baseUrl": ".", // 用于路径解析的基URL
    "paths": { // 类似于 tsconfig.json 的 paths，用于模块路径别名
      // "@/components/*": ["src/components/*"]
    }
  },
  "module": { // 模块系统配置
    "type": "es6", // 输出的模块类型: "es6", "commonjs", "amd", "umd", "systemjs"
    "strict": false, // 是否启用严格模式 "use strict";
    "strictMode": true, // (同上)
    "lazy": false, // 是否懒加载模块 (某些模块系统)
    "noInterop": false, // 是否禁用 Babel 风格的 __esModule interop
    "ignoreDynamic": false // 是否忽略动态导入的转换
  },
  "minify": false, // 是否启用代码压缩 (true/false)
  // 或者更详细的压缩配置对象 (Terser 兼容的选项)
  // "minify": {
  //   "compress": {
  //     "unused": true
  //   },
  //   "mangle": true // 是否混淆名称
  // },
  "sourceMaps": true, // "inline" 或 true/false
  "inlineSourcesContent": true, // 是否将源文件内容内联到 source map 中
  "isModule": "unknown", // "unknown", true, false. 指示输入是否为 ES 模块
  "inputSourceMap": false, // 是否使用输入的 source map
  "program": { // 高级配置，通常不需要手动设置
    // ...
  },
  "filename": "", // 用于错误报告的文件名
  "cwd": ".", // 当前工作目录
  "env": { // 基于 NODE_ENV 的特定配置
    "development": {
      "jsc": {
        "transform": {
          "react": {
            "development": true,
            "refresh": true // 假设在开发中启用了 Fast Refresh
          }
        }
      },
      "sourceMaps": "inline"
    },
    "production": {
      "minify": true,
      "jsc": {
        "transform": {
          "react": {
            "development": false
          }
        },
        "keepClassNames": false
      }
    }
  },
  "plugin": undefined // WASM 插件配置 (实验性)
  // "plugin": (m) => new MyPluginVisitor(m) // 对于 JS 包装的 WASM 插件
}

示例 .swcrc (简化版，用于将 ESNext+TS+JSX 编译为 ES5 CommonJS):

{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": true,
      "dynamicImport": true,
      "decorators": true
    },
    "transform": {
      "react": {
        "runtime": "automatic"
      },
      "legacyDecorator": true,
      "decoratorMetadata": true // 如果使用 tsc 的 emitDecoratorMetadata
    },
    "target": "es5", // 目标环境
    "externalHelpers": true // 推荐，减小文件体积
  },
  "module": {
    "type": "commonjs" // 输出 CommonJS 模块
  },
  "sourceMaps": true,
  "minify": false // 通常在生产构建的最后阶段由打包工具统一处理压缩
}

3.4. Programmatic API (@swc/core)

你可以在 Node.js 脚本中直接使用 @swc/core 的 API。

// example.js
const swc = require('@swc/core');
const fs = require('fs');
const path = require('path');

const inputFile = path.join(__dirname, 'src/app.ts');
const outputFile = path.join(__dirname, 'dist/app.js');
const code = fs.readFileSync(inputFile, 'utf-8');

async function compileCode() {
  try {
    // 1. 编译代码 (transform)
    const result = await swc.transform(code, {
      filename: inputFile, // 重要，用于错误信息和某些转换
      jsc: {
        parser: {
          syntax: 'typescript',
          tsx: true,
        },
        transform: {
          react: {
            runtime: 'automatic',
          },
        },
        target: 'es2017',
      },
      module: {
        type: 'commonjs',
      },
      sourceMaps: true,
    });

    console.log('--- Transformed Code ---');
    console.log(result.code);
    console.log('--- Source Map ---');
    console.log(result.map);

    if (!fs.existsSync(path.dirname(outputFile))) {
      fs.mkdirSync(path.dirname(outputFile), { recursive: true });
    }
    fs.writeFileSync(outputFile, result.code);
    if (result.map) {
      fs.writeFileSync(outputFile + '.map', result.map);
    }
    console.log(`Successfully transformed ${inputFile} to ${outputFile}`);

    // 2. 仅解析代码 (parse)
    const ast = await swc.parse(code, {
      syntax: 'typescript',
      tsx: true,
    });
    console.log('\n--- AST (Abstract Syntax Tree) ---');
    // console.log(JSON.stringify(ast, null, 2)); // AST 会非常大

    // 3. 压缩代码 (minify)
    const es5CodeForMinify = `
      function longFunctionName(veryLongArgumentName) {
        const anotherLongVariableName = veryLongArgumentName + 1;
        if (true) { // Dead code
          console.log("This should be removed");
        }
        return anotherLongVariableName;
      }
      longFunctionName(10);
    `;
    const minifiedResult = await swc.minify(es5CodeForMinify, {
      // Terser 兼容的压缩选项
      compress: {
        unused: true,
        dead_code: true,
        // global_defs: {
        //   "@__DEV__": "false"
        // }
      },
      mangle: { // 名称混淆
        // topLevel: true,
      },
      sourceMap: true,
      // module: true, // 如果输入是 ES 模块
    });
    console.log('\n--- Minified Code ---');
    console.log(minifiedResult.code);
    console.log('--- Minified Source Map ---');
    console.log(minifiedResult.map);

  } catch (error) {
    console.error('SWC Error:', error);
  }
}

compileCode();

// src/app.ts (示例输入文件)
// export const Greeter = (name: string): string => {
//   const message = `Hello, ${name}!`;
//   console.log(message);
//   return message;
// };
//
// const element = <div>This is JSX</div>;
//
// async function testAsync() {
//   await new Promise(resolve => setTimeout(resolve, 100));
//   return "done";
// }
//
// testAsync().then(console.log);

运行上述脚本 (假设你创建了 src/app.ts):
node example.js

3.5. 与构建工具集成

SWC 的高性能使其成为现代构建工具的理想选择：

• Next.js: 从版本 11 开始，Next.js 默认使用 SWC 作为其 JavaScript/TypeScript 编译器，显著提升了构建速度和开发体验。

• Parcel: Parcel 2 也使用 SWC 进行快速的 JavaScript 和 TypeScript 转换。

• Vite: 虽然 Vite 主要使用 esbuild 进行预构建和开发时的快速转换，但社区也提供了 vite-plugin-swc 或类似插件，允许在 Vite 项目中使用 SWC 进行转换 (例如，如果需要 SWC 特有的某些转换或插件)。

• Webpack: 可以使用 swc-loader 来替代 babel-loader，从而在 Webpack 构建流程中利用 SWC 的速度优势。

  // webpack.config.js (swc-loader 示例)
  module.exports = {
    module: {
      rules: [
        {
          test: /.m?js$/,
          exclude: /(node_modules)/,
          use: {
            loader: 'swc-loader', // npm install --save-dev swc-loader @swc/core
            options: { // 这些选项会传递给 @swc/core
              jsc: {
                parser: {
                  syntax: 'ecmascript',
                  jsx: true,
                  dynamicImport: true
                },
                target: 'es2017'
              },
              module: {
                type: 'es6'
              }
              // 也可以在这里直接引用 .swcrc 文件:
              // configFile: path.resolve(__dirname, '.swcrc'),
            }
          }
        },
        {
          test: /.tsx?$/,
          exclude: /(node_modules)/,
          use: {
            loader: 'swc-loader',
            options: {
              jsc: {
                parser: {
                  syntax: 'typescript',
                  tsx: true,
                  dynamicImport: true
                },
                target: 'es2017'
              },
              module: {
                type: 'es6'
              }
            }
          }
        }
      ]
    }
  };
  

4. SWC 的工作原理

SWC 的工作流程与 Babel 类似，也遵循经典的三阶段编译器模式：

1. 解析 (Parsing):

   • 词法分析 (Lexing): SWC 的词法分析器 (lexer) 读取源代码字符串，并将其分解为一系列的词法单元 (Tokens) 。例如，const x = 10; 会被分解成 const (Keyword), x (Identifier), = (Punctuator), 10 (NumericLiteral), ; (Punctuator)。
   • 语法分析 (Parsing): 语法分析器 (parser) 根据语言的语法规则（ECMAScript, TypeScript, JSX），将词法单元流转换为抽象语法树 (Abstract Syntax Tree, AST) 。SWC 有自己的 AST 定义，虽然与 ESTree (Babel 使用的) 概念上相似，但在具体结构和节点类型上可能存在差异。
   • 这一阶段完全在 Rust 中高效执行。

2. 转换 (Transformation):

   • SWC 遍历 AST，并应用各种转换规则。这些规则可以：

     • 将新的语法特性转换为旧的等效语法 (如箭头函数转为普通函数)。
     • 移除 TypeScript 类型注解。
     • 转换 JSX 为函数调用。
     • 执行代码优化和压缩。

   • 转换逻辑由 SWC 内置的转换器和插件提供。

     • 内置转换器： 大部分常见的 ESNext 到 ES5/ES3 的转换、TypeScript 转换、JSX 转换以及代码优化都是内置的，并且是用 Rust 实现的，因此速度极快。

     • 插件：

       • Rust 插件 (.wasm 或动态链接库): 开发者可以用 Rust 编写自定义的转换逻辑，编译成动态库或 WASM 模块供 SWC 加载。这是实现复杂或特定领域转换的主要方式，性能最佳。
       • JavaScript 插件 (via WASM - 实验性/发展中): SWC 正在积极发展对 WASM 插件的支持。理论上，这允许使用 JavaScript/TypeScript (或其他语言) 编写插件，然后编译到 WASM。这降低了插件开发的门槛，但相比纯 Rust 插件，可能会有一些性能开销和功能限制。目前，通过 JavaScript 编写 SWC 插件的生态还不如 Babel 成熟。

3. 代码生成 (Code Generation):

   • 转换阶段完成后，SWC 的代码生成器会遍历修改后的 AST，并将其转换回 JavaScript 代码字符串。
   • 同时，如果配置了，它还会生成 Source Map，将生成代码中的位置映射回原始代码中的位置。
   • 这一阶段同样在 Rust 中高效完成。

关键在于 Rust： SWC 的核心优势源于其主要组件都是用 Rust 实现的。Rust 是一种系统编程语言，注重性能、内存安全和并发性。与解释执行的 JavaScript (Babel 的主要实现语言) 相比，编译后的 Rust 代码通常能更直接地利用硬件资源，执行效率更高。

5. SWC 能否取代 Babel？SWC 与 Babel 的区别

这是一个备受关注的问题，答案是“在很多场景下可以，但并非所有场景都完美取代”。

SWC 与 Babel 的主要区别：

特性	SWC (Speedy Web Compiler)	Babel
主要语言	Rust	JavaScript
性能	极高 (通常比 Babel 快 10-70 倍，取决于具体任务)	相对较慢 (JavaScript 解释执行的开销)
核心功能	编译 (JS/TS/JSX), 压缩, 打包 (实验性)	编译 (JS/JSX, TS 通过插件), Polyfill (通过 core-js)
插件生态	发展中。主要为 Rust 插件，WASM 插件是趋势。数量和成熟度不如 Babel。	极其庞大和成熟。几乎所有 JS 转换需求都有现成的 JS 插件。
插件开发	Rust 插件门槛较高；WASM 插件有望降低门槛。	JavaScript 插件开发门槛低，社区贡献活跃。
配置	.swcrc (JSON)	.babelrc.js, babel.config.js (JS), .babelrc (JSON) 等
成熟度	较新，但发展迅速，已被大型项目 (Next.js, Parcel) 采用。	非常成熟，久经考验，社区庞大。
Polyfill	SWC 本身不直接提供 polyfill，但其转换可以与 core-js 等配合。@swc/helpers 提供辅助函数，类似 @babel/runtime。	通过 @babel/preset-env 和 core-js 深度集成 Polyfill 方案。
可定制性	内置转换覆盖广泛；复杂或特定转换依赖插件。	极高，几乎任何代码转换都可以通过插件实现。
社区支持	快速增长，但与 Babel 相比仍有差距。	巨大且活跃。
错误报告	持续改进中。	通常比较友好和详细。
实验性特性支持	积极跟进，但可能略慢于 Babel 社区插件的响应速度。	Babel 插件通常能非常快速地支持最新的语言提案。

SWC 能否取代 Babel？

• 对于性能敏感的项目和追求极致构建速度的场景： SWC 是一个非常有吸引力的选择，尤其是在编译和压缩这些核心任务上。Next.js 和 Parcel 的采用证明了其在生产环境中的可行性。
• 对于需要大量特定 Babel 插件或高度自定义转换的项目： 如果你的项目严重依赖某些只有 Babel 才有的插件，或者需要非常复杂的、用 JavaScript 编写的自定义 Babel 插件，那么迁移到 SWC 可能需要更多的工作，甚至暂时不可行，直到 SWC 的 WASM 插件生态更加成熟或有对应的 Rust 插件出现。
• 新项目： 对于新项目，如果其需求能被 SWC 的核心功能和现有插件覆盖，那么选择 SWC 可以从一开始就享受性能优势。
• 逐步替换： 在某些项目中，可以考虑混合使用，例如使用 SWC 进行大部分的编译工作，而对某些特殊文件或转换仍然使用 Babel。

总结：

• SWC 的核心竞争力在于其无与伦比的速度。
• Babel 的核心竞争力在于其极其成熟和庞大的 JavaScript 插件生态以及由此带来的高度灵活性和可扩展性。

随着 SWC WASM 插件生态的发展，SWC 的可扩展性短板正在被弥补。未来，SWC 有望在更多场景下成为 Babel 的有力替代者，甚至主流选择。

6. SWC 的插件系统简述

如前所述，SWC 的插件系统是其扩展能力的关键。

• Rust 插件：

  • 直接使用 SWC 的 Rust API (swc_core::ecma::visit::Fold 或 swc_core::ecma::visit::VisitMut) 来遍历和修改 AST。

  • 编译为动态链接库 (.dylib, .so, .dll) 或 WASM 模块。

  • 性能最佳，可以直接操作 Rust 数据结构。

  • 开发门槛相对较高，需要 Rust 编程经验。

  • 示例概念 (非真实可运行插件，仅为示意):

    // 这是一个非常概念化的 Rust 插件思路
    // use swc_core::ecma::ast::*;
    // use swc_core::ecma::visit::{Fold, FoldWith};
    // use swc_core::plugin::proxies::TransformPluginProgramMetadata;
    // use swc_core::plugin::{plugin_transform, PluginError};
    
    // pub struct MyCustomTransformer;
    
    // impl Fold for MyCustomTransformer {
    //     // 示例：将所有标识符 'foo' 重命名为 'bar'
    //     fn fold_ident(&mut self, ident: Ident) -> Ident {
    //         if ident.sym.to_string() == "foo" {
    //             return Ident::new("bar".into(), ident.span);
    //         }
    //         ident
    //     }
    
    //     // 你可以重写更多 fold_xxx 方法来处理不同类型的 AST 节点
    // }
    
    // #[plugin_transform]
    // pub fn process_transform(program: Program, _metadata: TransformPluginProgramMetadata) -> Result<Program, PluginError> {
    //     let mut transformer = MyCustomTransformer;
    //     Ok(program.fold_with(&mut transformer))
    // }
    

    实际的 SWC Rust 插件开发会涉及更多细节，如处理 Span (源码位置信息)、与 SWC 的插件宏交互等。

• WASM 插件：

  • 目标是允许用更广泛的语言（包括 JS/TS）编写插件。

  • 插件逻辑被编译成 WebAssembly 模块。

  • SWC 会在沙箱环境中加载和执行这些 WASM 模块。

  • 相比 Rust 插件，可能存在一定的性能开_overhead_ (WASM 与宿主环境的交互、数据序列化等)，但依然远快于纯 JS 插件在 JS 引擎中的执行。

  • 降低了插件开发门槛，有望构建更丰富的插件生态。

  • 配置方式通常是在 .swcrc 中指定 WASM 文件的路径和一些元数据。

    // .swcrc 中 WASM 插件配置示例 (概念性)
    // {
    //   "jsc": {
    //     "experimental": {
    //       "plugins": [
    //         ["/path/to/my-plugin.wasm", { /* plugin options */ }]
    //       ]
    //     }
    //     // ...
    //   }
    // }
    

  • 目前，围绕 SWC 的 JS-to-WASM 插件工具链和生态仍在积极建设中。

7. 局限性和注意事项

• 插件生态系统： 虽然在快速发展，但与 Babel 相比，SWC 的插件数量和成熟度仍有差距。许多 Babel 特有的、小众的或高度定制化的插件可能在 SWC 中找不到直接的替代品。
• 实验性功能： SWC 的某些功能（如打包器 spack、部分插件 API）可能仍处于实验阶段，API 可能会发生变化。
• 配置复杂度： 虽然 SWC 提供了丰富的配置选项，但对于初学者来说，理解所有选项并正确配置可能需要一些学习成本。
• 错误信息： 虽然在不断改进，但在某些复杂情况下，SWC 的错误提示可能不如 Babel 那样详尽或易于理解。
• 社区和文档： SWC 的社区正在壮大，文档也在不断完善，但与 Babel 悠久的历史和庞大的社区资源相比，遇到问题时可能需要更多的自行探索。

8. 总结与展望

SWC 是前端构建工具领域一个非常令人兴奋的进展。它通过利用 Rust 的强大性能，为 JavaScript/TypeScript 开发带来了显著的速度提升，解决了传统工具链在大型项目中的性能瓶颈问题。

• 对于核心编译和压缩任务，SWC 已经是一个非常成熟和高效的选择。
• 它正在被越来越多的主流框架和工具所采用。
• 其插件系统（尤其是 WASM 插件）的发展，将是决定其未来能否更广泛取代 Babel 的关键因素。

如果你追求极致的构建性能，并且项目需求主要集中在标准的语言转换和优化上，那么 SWC 非常值得尝试。对于依赖复杂 Babel 插件生态的项目，则需要评估迁移成本和可行性。

由于 SWC 仍在快速迭代，建议关注其官方 GitHub 仓库和文档以获取最新的信息和功能更新。