Esbuild/SWC 架构分析：Go/Rust 如何通过 FFI 与 JavaScript 共享 AST 数据

大家好，我是今天的主讲人。今天我们来深入探讨一个在现代前端构建工具中越来越常见的技术命题：如何让 Go 或 Rust 编写的高性能编译器（如 esbuild、SWC）通过 FFI（Foreign Function Interface）与 JavaScript 共享抽象语法树（AST）？

这不仅是性能优化的关键点，也是跨语言协作的典范实践。我们将从底层原理出发，逐步拆解其架构设计，并结合真实代码示例说明实现细节。

---

一、背景：为什么需要 FFI + AST 共享？

在传统 Node.js 生态中，很多构建工具（如 Babel、TypeScript 编译器）是纯 JS 实现的。它们虽然灵活易用，但存在明显瓶颈：

• 执行效率低：JavaScript 引擎对复杂 AST 操作（比如遍历、转换）性能较差；
• 内存占用高：大量中间对象堆叠导致 GC 压力大；
• 扩展性差：难以支持多线程并行处理或原生模块加速。

于是，像 esbuild 和 SWC 这样的项目应运而生——它们用 Go 或 Rust 写核心编译逻辑，再通过 FFI 接口暴露给 JavaScript 使用。

✅ 关键价值：

• 利用 Go/Rust 的零成本抽象和并发能力提升编译速度；
• 在 JS 端保持 API 友好性和生态兼容性；
• AST 数据可以在不同语言间高效传递，避免重复解析。

---

二、核心挑战：AST 是什么？怎么共享？

1. AST 是什么？

抽象语法树（Abstract Syntax Tree）是对源码结构化的表示形式，例如这段 JavaScript：

const x = 1 + 2;

会被解析为如下 AST（简化版）：

{
  "type": "Program",
  "body": [
    {
      "type": "VariableDeclaration",
      "declarations": [
        {
          "type": "VariableDeclarator",
          "id": { "type": "Identifier", "name": "x" },
          "init": {
            "type": "BinaryExpression",
            "operator": "+",
            "left": { "type": "Literal", "value": 1 },
            "right": { "type": "Literal", "value": 2 }
          }
        }
      ]
    }
  ]
}

这个结构是跨语言通用的，但它不是“原生类型”——JS 中是对象，Go/Rust 中可能是 struct 或 enum。

2. 核心挑战：如何安全地在不同语言之间传递 AST？

挑战	描述
类型不一致	JS 对象 vs Go struct / Rust enum
内存管理差异	JS 垃圾回收 vs Go/Rust 手动/自动内存控制
性能损耗	序列化/反序列化开销过大
安全风险	不当访问可能造成崩溃或内存泄漏

解决这个问题的核心思路是：使用统一的数据格式 + 显式边界 + 跨语言绑定层。

---

三、Esbuild 和 SWC 的架构对比（表格）

特性	esbuild (Go)	SWC (Rust)
主要语言	Go	Rust
AST 表示方式	JSON 字符串（via FFI）	自定义 C-compatible 结构体（via FFI）
数据传输方式	将 AST 序列化为 JSON 字符串传入 JS	直接暴露 C-compatible struct 指针
内存模型	Go 的 GC + Cgo 托管	Rust 的所有权 + FFI-safe wrapper
性能表现	快速但有 JSON 序列化开销	极快，无额外拷贝
开发难度	较低（Go 与 JS 交互简单）	较高（需理解 Rust 生命周期）

👉 结论：

• 如果追求极致性能且愿意承担开发复杂度 → 选 SWC（Rust + C ABI）；
• 如果快速集成、团队熟悉 Go → 选 esbuild（JSON 通信）；

---

四、案例详解：Swc 的 AST 共享机制（Rust → JS）

我们以 SWC 为例，展示它是如何做到高效的 AST 共享的。

步骤 1：定义 C-friendly 的 AST 结构体（Rust）

// src/lib.rs
use std::os::raw::{c_void, c_int};

#[repr(C)]
pub struct SwcAstNode {
    pub ty: c_int,
    pub start: usize,
    pub end: usize,
    // 可扩展字段，如标识符、表达式等
}

#[repr(C)]
pub struct SwcAstProgram {
    pub body: *mut SwcAstNode,
    pub len: usize,
}

// 提供一个函数，将 Rust AST 转为 C-compatible 结构
#[no_mangle]
pub extern "C" fn swc_parse_js(code: *const i8) -> *mut SwcAstProgram {
    let code_str = unsafe { std::ffi::CStr::from_ptr(code).to_str().unwrap() };

    // 解析 JS 代码成 AST（这里省略实际解析逻辑）
    let ast = parse_js(code_str); // 假设这是一个返回 SwcAstProgram 的函数

    Box::into_raw(Box::new(ast))
}

// 释放内存（必须由 JS 调用）
#[no_mangle]
pub extern "C" fn swc_free_ast(ast: *mut SwcAstProgram) {
    if !ast.is_null() {
        unsafe {
            drop(Box::from_raw(ast));
        }
    }
}

⚠️ 注意：

• #[repr(C)] 确保结构体布局符合 C ABI；
• 使用裸指针 (*mut T) 来暴露数据给外部调用；
• 所有分配都用 Box::into_raw()，释放时用 drop(Box::from_raw())。

步骤 2：Node.js 绑定（JavaScript）

// binding.js
const ffi = require('ffi-napi');
const ref = require('ref-napi');

// 定义结构体映射
const SwcAstNode = ref.types.struct({
  ty: 'int',
  start: 'uint32',
  end: 'uint32'
});

const SwcAstProgram = ref.types.struct({
  body: 'pointer',
  len: 'uint32'
});

// 加载动态库（假设编译后为 libswc.so）
const swcLib = ffi.Library('./build/swc', {
  swc_parse_js: ['pointer', ['string']],
  swc_free_ast: ['void', ['pointer']]
});

function parseJs(code) {
  const astPtr = swcLib.swc_parse_js(code);

  const ast = new SwcAstProgram();
  ast.readFrom(astPtr);

  // 获取节点数组（需手动遍历）
  const nodes = [];
  for (let i = 0; i < ast.len; i++) {
    const nodePtr = ref.reinterpret(ast.body, 0, i * ref.sizeOf(SwcAstNode));
    const node = new SwcAstNode();
    node.readFrom(nodePtr);
    nodes.push(node);
  }

  // 最后记得释放内存！
  swcLib.swc_free_ast(astPtr);

  return nodes;
}

✅ 这样做的好处：

• 零拷贝：直接操作内存地址，无需 JSON 序列化；
• 高性能：适合大规模 AST 处理（如打包、tree-shaking）；
• 可控性强：可以精确控制生命周期。

❌ 缺点：

• 需要手动管理内存（容易出错）；
• JS 层需了解底层结构，维护成本较高。

---

五、Esbuild 的做法：JSON 序列化 + Go FFI（更友好）

相比之下，esbuild 更倾向于“透明化”这一过程，它把整个 AST 序列化成 JSON 字符串传给 JS。

示例：Go 中生成 AST 并返回 JSON

package main

import (
    "encoding/json"
    "fmt"
    "log"
)

type Node struct {
    Type string `json:"type"`
    // 其他字段...
}

func ParseJS(code string) ([]byte, error) {
    ast := &Node{Type: "Program"}

    // 模拟解析逻辑（实际用 go-javascript-parser）
    // ...

    result, err := json.Marshal(ast)
    if err != nil {
        return nil, fmt.Errorf("failed to marshal AST: %v", err)
    }

    return result, nil
}

// 导出为 C 函数供 JS 调用
//export parse_js
func parse_js(code *C.char) *C.char {
    codeStr := C.GoString(code)
    astBytes, err := ParseJS(codeStr)
    if err != nil {
        log.Printf("Parse error: %v", err)
        return nil
    }

    return C.CString(string(astBytes))
}

func main() {}

Node.js 调用方式：

const ffi = require('ffi-napi');
const ref = require('ref-napi');

const swcLib = ffi.Library('./build/esbuild', {
  parse_js: ['string', ['string']]
});

function parseJs(code) {
  const jsonStr = swcLib.parse_js(code);
  return JSON.parse(jsonStr);
}

console.log(parseJs('const a = 1 + 2;'));
// 输出: { type: "Program", ... }

✅ 优点：

• JS 端完全透明，无需关心底层结构；
• 错误处理简单（JSON.parse 可捕获异常）；
• 易于调试（可打印 AST 字符串）；

❌ 缺点：

• 每次都要做 JSON 序列化/反序列化，有一定开销；
• 不适合超大规模 AST（如百万级节点）；

---

六、总结：两种方案的选择建议

场景	推荐方案	理由
快速原型、中小项目	esbuild 方案（Go + JSON）	易上手、易调试、适合大多数场景
高性能要求、大型项目	SWC 方案（Rust + C ABI）	零拷贝、极致性能、适合高频 AST 操作
团队熟悉 Go	esbuild	Go 的 FFI 支持完善，学习曲线平缓
团队熟悉 Rust	SWC	Rust 的内存安全特性保障稳定性

📌 关键洞察：

• AST 共享的本质不是“复制”，而是“引用”；
• FFI 的关键是边界清晰 + 生命周期可控；
• 不同语言之间的 AST 共享，本质是一个跨进程/跨语言的数据契约问题。

---

七、延伸思考：未来趋势

随着 WebAssembly 的普及，我们可能会看到更多这样的组合：

• Wasm + JS AST 共享：Go/Rust 编译为 Wasm，直接嵌入浏览器运行；
• LLVM IR + AST 合并：利用 LLVM 的中间表示进一步优化 AST 转换；
• 增量编译 + AST diff：基于 AST 差异做局部更新，而非全量重编译。

这些方向都在推动构建工具进入下一个阶段：更快、更智能、更轻量。

---

结语

今天我们系统分析了 esbuild 和 SWC 如何通过 FFI 实现 AST 数据共享。无论是 Go 的 JSON 透明封装，还是 Rust 的 C-compatible 结构体直通，都是现代工程实践中极具价值的解决方案。

希望你能从中获得启发：不要害怕跨语言协作，只要设计得当，性能与易用性完全可以兼得。

如果你正在构建自己的编译工具链，不妨考虑引入 Go 或 Rust 作为“加速引擎”，然后用 JavaScript 提供用户友好的 API —— 这正是当今工业级工具的标准模式。

谢谢大家！欢迎提问。