Bun 换核启示录：从 Zig 到 Rust，一次 AI 驱动的大型系统迁移工程全记录

2026年5月14日，一个编号为 PR #30412 的合并提交悄然躺在 oven-sh/bun 的 GitHub 仓库里。标题平淡无奇——Rewrite Bun in Rust——但其规模足以让任何一个系统程序员倒吸一口凉气：6755 个提交、2188 个文件变更、超过 100 万行新增代码。更令人意外的是，这次迁移的主导者，并不是一个由资深 C++ 工程师组成的传统团队，而是一套由 AI 辅助、规则驱动的流水线。

这是 2026 年软件开发史上最具标志性的工程实验之一。它不仅是一次语言迁移，更是对"AI 能参与多大工程"这个问题的一次公开回答。

一、背景：为什么是现在？

要理解这次迁移的意义，先要理解 Bun 是什么、它从哪里来、以及为什么它需要换核。

1.1 Bun 的诞生与定位

Bun 由 Jarred Sumner 创建，最初的愿景是打造一个一体化（All-in-One）的 JavaScript/TypeScript 工具链。不同于 Node.js 和 Deno，Bun 不仅是一个运行时，它还同时包含了：

• 运行时（Bun Runtime）：基于 JavaScriptCore 引擎，号称比 Node.js 冷启动快 4-6 倍
• 包管理器（Bun Install）：比 npm 快 100 倍，支持 lockfile v1/v2
• 打包工具（Bun Build）：内置 bundler
• 测试框架（Bun Test）：兼容 Jest API，速度远超 Jest
• 脚本运行器：原生 TypeScript 支持，无需额外配置

Bun 最初使用 Zig 语言编写。选择 Zig 的核心理由是：Zig 提供了与 C 语言的无缝互操作能力，同时避免了 C++ 的复杂性，并且对编译时控制和内存管理有精细的表达能力。这对于一个需要直接操作 JavaScriptCore 引擎、与操作系统底层交互的高性能运行时来说，是理想选择。

1.2 2025 年底：转折点

2025 年 12 月 3 日，Anthropic 宣布收购 Bun。这一交易让很多人意外，但逻辑其实很清晰：Anthropic 的 Claude Code 等 AI 编程工具对每秒执行速度极为敏感。当 Claude Code 需要在用户机器上快速执行脚本、安装依赖、运行测试时，Bun 的性能优势直接转化为用户体验优势。

被收购后，Bun 获得了更多资源支持，也正是在这个背景下，Rust 重写计划正式启动——尽管最初被描述为"实验分支，可能扔掉"。

1.3 一个工程问题的本质

从 Zig 到 Rust 的迁移，表面上看是一个语言选择问题，但本质上是一个工程债务与长期维护成本的问题。

Zig 语言的优势在于底层控制能力，但它相对年轻，生态还不够成熟，工具链也没有 Rust 完善。在 Zig 中处理复杂的内存管理、多线程安全性、跨平台兼容性时，团队需要投入大量精力自己解决 Rust 标准库已经解决好的问题。

Jarred Sumner 本人在社区讨论中透露："这几年，内存安全相关的 bug 消耗了团队大量开发和调试时间。" 这句话揭示了迁移的根本动机——不是追求更快的性能，而是追求更低的 bug 率和更高的开发效率。

Rust 的编译器、类型系统、借用检查器、工具链生态（cargo、rust-analyzer、miri 等）能够自动捕获大量此前需要人工排查的问题。

二、迁移全景：6755 次提交背后的流水线

2.1 两个时代的对比

Deno 当年的迁移本质上还是传统的"人读代码、人写代码、人修 bug"模式。而 Bun 这次发生在 AI 编程工具已经相当成熟的阶段——Claude Code 已经能够理解和生成复杂的多文件 Rust 代码，这从根本上改变了迁移的成本结构。

2.2 PORTING.md：迁移规则的宪法

Bun 仓库中出现了两个关键文件：PORTING.md 和 .claude/workflows/ 目录。

PORTING.md 是整个迁移的"宪法"，它规定了迁移的两阶段哲学：

• Phase A（忠实翻译阶段）：将 Zig 文件翻译成同目录下的 Rust 草稿文件，目标是精确捕捉原有逻辑，不要求立即编译通过。这个阶段允许生成大量"能跑但丑"的代码。
• Phase B（工程化阶段）：按 crate 逐个解决编译错误、所有权问题、跨平台兼容性和性能优化。

这种分阶段策略非常关键。它把"能不能跑起来"和"跑得好不好"解耦了，让 AI 可以专注于第一阶段的忠实翻译，而不必同时处理所有复杂的工程问题。

PORTING.md 中对迁移规则的描述非常具体，例如：

• 哪些标准库不能引入
• 哪些架构设计不能改变
• 哪些类型映射关系必须保持
• 哪些 allocator 语义要保留（Zig 和 Rust 的内存分配语义不完全一致）
• 哪些 unsafe 边界只是从 Zig 世界搬到了 Rust 世界，必须保持一一对应

规则越细，AI 越不容易自由发挥。 这是 AI 辅助大型工程迁移的核心心法。

2.3 .claude/workflows：流水线分工

Bun 的 .claude/workflows 目录中定义了多个自动化工作流，每个工作流负责迁移流程的一个专门环节：

.claude/workflows/
├── translate-zig-to-rust.yml      # Zig → Rust 草稿翻译
├── validate-mappings.yml            # 规则验证（边界条件检查）
├── fix-compile-errors.yml          # 编译错误修复
├── classify-lifetimes.yml           # 生命周期分类
├── audit-unsafe.yml                # unsafe 代码审计
└── windows-bughunt.yml             # Windows 平台专项排查

每个工作流都是一个专门化的 AI agent，各司其职、流水线协作。这种"分而治之"的思路，避免了让一个通用 agent 承担所有迁移任务导致的混乱。

这个设计揭示了一个重要趋势：未来大型工程中，开发者的重要产出会从"代码本身"变成"约束与规则"。你设计的不是代码，而是一个能让 AI 安全工作、错误尽早暴露的工程系统。

2.4 迁移的规模数据

合并后的数据令人印象深刻：

• 6755 个提交
• 2188 个文件变更
• 新增代码超过 100 万行
• 二进制体积缩小 3-8 MB（这在系统级软件中是显著优化）
• Benchmark 结果：持平到更快
• 全平台通过现有测试套件

最后一点特别值得强调：虽然这是一个几乎完全重写的版本，但 Bun 团队让它通过了既有的 Zig 版测试套件。这意味着迁移后的行为语义被尽可能保留了，回归风险得到了控制。

三、13365 个 unsafe：Rust 换核的代价

3.1 unsafe 是什么？

在深入分析数字之前，有必要先厘清 Rust 中 unsafe 的含义。

Rust 的核心哲学是内存安全——通过所有权（ownership）、借用（borrowing）和生命周期（lifetimes）系统，编译器在编译期就能阻止大多数内存安全问题（悬垂引用、数据竞争、重复释放等）。

但 Rust 也要和现实世界打交道：C 库调用、操作系统接口、手写内存布局、JIT 编译、垃圾回收、跨语言对象生命周期——这些场景超出了 Rust 借用检查器能够自动验证的范围。

unsafe 是 Rust 提供的边界标记，它允许程序员做 5 类平时编译器不允许的事情：

// 1. 解引用裸指针
let raw_ptr = some_ptr as *const u8;
let value = unsafe { *raw_ptr };

// 2. 调用 unsafe 函数（外部 C 接口等）
unsafe {
    some_c_function(ptr, len);
}

// 3. 访问或修改可变静态变量
static mut COUNTER: u32 = 0;
unsafe { COUNTER += 1; }

// 4. 实现 unsafe trait
unsafe impl Send for MyCustomType {}

// 5. 标记 unsafe 函数（告诉调用者需要自己保证某些不变式）
unsafe fn dangerous_operation(data: *mut u8, len: usize) { ... }

关键点：unsafe 是责任转移，不是能力赋予。它把"编译器替你证明"变成了"你自己证明"。Rust 并不认为所有 unsafe 都是坏的——很多底层操作根本不可能在 safe Rust 中完成。

3.2 13365 个 unsafe 的真相

Bun 团队在预发布阶段主动公开了一次全面的 unsafe 审计。初始数字确实惊人：13,365 个 unsafe 代码块。

但"13,365"是一个入口，不是判决书。原文对这些数字做了精确分类：

实际执行中的 unsafe 代码块约为 10,575 个（不含声明类匹配）。

3.3 四类 unsafe 来源详解

第一类：Zig Port Legacy（迁移遗留）

这是数量最大的一类。Zig 对内存、别名、生命周期有完全不同于 Rust 的表达方式。

在 Zig 中，手动管理内存、通过显式的 deinit 释放资源、使用原始指针是常态。这种风格在翻译成 Rust 时，初期会大量使用裸指针和手动 unsafe 块。

例如，Zig 中的一个内存缓冲区：

const std = @import("std");
fn createBuffer(size: usize) ![]u8 {
    const memory = try std.heap.page_allocator.alloc(u8, size);
    // ... 使用内存
    return memory;
}

翻译成 Rust 的初期版本，可能变成：

fn create_buffer(size: usize) -> Result<&'static [u8], Error> {
    let memory = unsafe {
        std::alloc::alloc(std::alloc::Layout::from_size_align_unchecked(size, 1))
    };
    // 初期版本：用裸指针和 unsafe 包裹
    unsafe {
        // 手动 memcpy / memset
    }
    Ok(unsafe { std::slice::from_raw_parts(memory, size) })
}

这显然不是"好的 Rust"，但它是 Phase A 的目标：先忠实翻译，再逐步优化。

第二类：FFI Boundary（跨语言边界）

Bun 需要与大量 C/C++ 库交互：

• JavaScriptCore：Apple 的 JavaScript 引擎，Bun 运行时核心
• uWebSockets/uSockets：高性能 WebSocket 实现
• libuv：跨平台异步 I/O（用于某些平台）
• BoringSSL：OpenSSL 分支，提供 TLS 加密
• c-ares：异步 DNS 解析
• zlib：压缩库

这些库都是 C/C++ 实现，Rust 编译器无法验证它们的内存安全承诺。因此，所有 FFI 调用点都必须使用 unsafe 标记。这不是 Bun 的问题，而是所有 Rust 与 C 互操作的共同特点。

第三类：Event-Loop Callback（事件循环回调）

事件循环是运行时系统的核心。Bun 的事件循环需要将 Rust 对象指针传递给 C 回调函数，等事件发生时再由 C 调用回来。

这个过程中存在几个 Rust 无法自动验证的问题：

// 伪代码示例
fn schedule_callback(data: *mut RustObject) {
    unsafe {
        // 将 Rust 对象指针传给 C 函数
        c_set_timeout_callback(data, callback_handler);
        // 此时 data 仍然拥有所有权吗？回调期间会重入吗？
        // 生命周期在这里变得模糊
    }
}

回调执行时：

1. Rust 对象 data 还活着吗？（可能在另一个线程已被释放？）
2. data 的类型还是原来的类型吗？（是否有 transmute？）
3. 回调过程中会重入 JavaScript 吗？重入时 data 是否会被修改？

这些问题在 Zig 中通过约定处理，在 Rust 中则必须显式表达生命周期约束。

第四类：Lifetime Workaround（生命周期绕路）

Rust 的生命周期系统极为强大，但它对某些运行时对象——特别是涉及 GC、跨语言引用计数、或者动态大小的对象——的表达能力有限。

Bun 需要管理 JavaScript 对象的 GC 引用、JS 侧的闭包与 Rust 侧的闭包之间的交叉引用、动态创建和销毁的 VM 实例——这些场景在 Rust 类型系统中没有自然的"生命周期参数"可以贴上去。

所以在迁移初期，工程师们选择先用较底层的形式绕过这些问题，待 Phase B 再逐步重构。

3.4 横向对比：unsafe 密度分析

Bun 团队做了一次有价值的横向对比，按"每千行 Rust 代码中的 unsafe 数量"排序：

这个对比告诉我们几个事实：

1. rusty_v8 的 unsafe 密度高是正常的，因为它本质上就是 V8 C++ API 的 Rust wrapper，不可能避免大量 unsafe
2. Bun 初始版本的 unsafe 密度高于 Deno，主要原因是 Zig 迁移遗留和更多的 FFI 依赖
3. Bun 的目标是 4.2，接近 tokio 水平，这是通过重构unsafe 分布来实现的

3.5 比 unsafe 数量更重要的问题：Safe API Soundness

审计中最值得关注的问题，不是 13,365 个 unsafe，而是 5 个 safe API soundness 问题。

这是 Rust 世界中最容易被忽视、也最危险的一类 bug。

在 safe Rust 中，调用者不需要自己证明内存安全——这是库作者的承诺。但如果一个 safe API 内部虽然用了 unsafe，却把不安全的内存状态通过 safe 接口泄漏了出去，调用者就会在"以为安全"的情况下触发未定义行为。

Bun 审计发现的 5 个 safe API soundness 问题包括：

// 问题 1：picohttp::Header 的 lifetime 问题
// Header::name() / value() 的返回值的生命周期
// 和 Header 对象本身不一致，导致悬垂引用

// 问题 2：ArrayBuffer::from_bytes 的借用保存问题
// 把 &mut [u8] 借用转换成 JS 可见对象
// 当 JS GC 持有这个引用时，原 Rust 借用的独占性被破坏
ArrayBuffer::from_bytes(bytes: &mut [u8], ...)
    // bytes 被保存为 JS 可见对象，但 bytes 的 &mut 独占借用仍然存在

// 问题 3：JsCell 的别名问题
// JsCell::get() 和 with_mut() / set() / replace() 之间
// 可能产生多个可变引用 aliasing 同一个对象——Rust 的禁区

// 问题 4：RacyCell 的无条件 Sync
// RacyCell 被标记为 Sync，但实际上在跨线程访问时存在数据竞争
unsafe impl Sync for RacyCell {} // 这个 unsafe impl 是错的

// 问题 5：VirtualMachine::as_mut(&self) -> &mut VirtualMachine
// &self → &mut 的 safe 转换，等于绕过了 Rust 的借用系统
// 同一 VM 实例上的两个 &self 调用可能同时触发 &mut 访问

这些问题的优先级高于 unsafe 数量，因为：

• FFI 的 unsafe 至少在告诉你：这里有边界，调用需谨慎
• safe API soundness 问题是边界消失了，调用者不知道自己在危险区域

四、Phase B 降 unsafe 策略：不是把关键字藏起来

4.1 策略一：先修 Safe API Soundness

这是最高优先级的任务。具体手段包括：

// 修复前：裸指针状态机
struct JsCell {
    ptr: *mut OpaqueJSValue,
}

// 修复后：用 checked cell 替代裸指针
use std::cell::Cell;
struct JsCell {
    ptr: Cell<*mut OpaqueJSValue>, // Cell 提供内部可变性，但有边界检查
}

4.2 策略二：把裸指针改成安全的容器封装

// 修复前：裸指针，生命周期不明
struct EventLoopCallback {
    user_data: *mut libc::c_void,
    callback: fn(*mut libc::c_void),
}

// 修复后：用 PhantomData 标记生命周期依赖
use std::marker::PhantomData;
struct EventLoopCallback<'a> {
    user_data: &'a mut libc::c_void, // 生命周期与外部绑定
    callback: fn(&mut libc::c_void),
    _phantom: PhantomData<&'a ()>,
}

4.3 策略三：FFI 边界用 safe wrapper 封装

// FFI 层（unsafe，不可避免）
unsafe fn c_send_data(ptr: *mut u8, len: usize) -> i32;

// Safe wrapper（封装 unsafe，暴露安全接口）
fn send_data(data: &[u8]) -> Result<(), IoError> {
    let len = data.len();
    let ptr = data.as_ptr() as *mut u8;
    unsafe {
        let result = c_send_data(ptr, len);
        if result < 0 {
            return Err(IoError::last_os_error());
        }
    }
    Ok(())
}

通过这种方式，把 unsafe 集中在 FFI 层，让上层的业务逻辑完全在 safe Rust 中运行。

4.4 降 unsafe 的误区

最常见的误区是：认为降 unsafe 就是减少 unsafe 关键字的出现次数。

实际上，如果把大量 unsafe 操作改写成 safe wrapper 但内部仍然用 transmute、raw pointer cast 等手段，风险并不会降低——只是被隐藏了。

正确的降 unsafe 路径是：

1. 先修 soundness：确保暴露给外部的 safe API 真正 sound
2. 再重构 unsafe 分布：把 unsafe 集中到少数模块，边界清晰
3. 最后优化 unsafe 数量：用 Rust 的安全抽象替代裸 unsafe 操作

五、AI 参与大型工程迁移的工程方法论

5.1 为什么 AI 能参与这件事

Bun 迁移能够大规模借助 AI，不是因为 AI 突然变聪明了，而是因为任务结构适合 AI。

Bun 团队把一个看似不可能的工程问题，分解成了多个结构化的子任务：

1. 翻译任务：Zig 代码 → Rust 代码（语法级映射，有明确的类型对应关系）
2. 验证任务：检查迁移后的代码是否满足 PORTING.md 中的规则
3. 修复任务：解决编译错误、类型不匹配
4. 审计任务：识别 unsafe 代码的分布和风险等级
5. 平台测试：在 Windows/Linux/macOS 上运行并对比行为

这些任务有一个共同特点：输入和输出都有明确结构，规则可以显式表达。AI 在这类任务上表现极好，因为 AI 的核心能力就是"在给定规则和上下文的条件下，高吞吐量地生成和验证结构化内容"。

5.2 AI 辅助大型迁移的三层架构

从 Bun 的实践中，我们可以提炼出 AI 辅助大型工程迁移的三层架构：

┌─────────────────────────────────────────────────────────┐
│  第一层：AI 负责吞吐                                        │
│  · 生成 Rust 草稿（Phase A 翻译）                           │
│  · 批量修复编译错误                                         │
│  · 自动扫描明显问题（类型不匹配、签名错误）                   │
│  · 运行自动验证（cargo check, cargo test）                  │
├─────────────────────────────────────────────────────────┤
│  第二层：工具负责约束                                        │
│  · Rust 编译器：类型系统、借用检查、生命周期分析               │
│  · miri：检测 unsafe 代码的未定义行为                       │
│  · cargo：依赖管理、跨平台构建                               │
│  · 工具链：rustfmt、rustfix、clippy                        │
│  · CI/CD：自动化测试套件、回归验证                          │
├─────────────────────────────────────────────────────────┤
│  第三层：人负责判断                                         │
│  · 架构边界：哪些设计必须保持不变                            │
│  · 发布节奏：canary → beta → stable                        │
│  · 风险评估：哪些 unsafe 可以接受，哪些必须优先修             │
│  · 兼容性判断：哪些行为变化是不可接受的                      │
└─────────────────────────────────────────────────────────┘

5.3 AI 的局限：哪些事 AI 做不了

即便有完善的规则和工具链，AI 在这次迁移中仍然面临局限：

1. 架构判断：当 Zig 和 Rust 的语义差异导致多个可行翻译方案时，AI 无法自主判断哪种方案在长期维护中更好
2. 性能调优：unsafe 代码的性能优化需要深入理解硬件和内存访问模式，这超出了代码级翻译的能力
3. 跨模块影响评估：修改一个底层模块可能影响数十个上游模块，这种全局影响分析需要人工判断
4. 兼容性与回归测试：AI 可以运行测试套件，但无法设计"什么样的边界条件测试能发现潜在 bug"

5.4 这次迁移对行业的启示

启示一：以前因为成本太高不敢做的迁移，现在可以重新评估

大量用 C/C++ 编写的老旧核心模块、没有测试覆盖的遗留服务、需要跨语言重写的 DSL——这些在过去因为人力成本过高而被搁置的工程决策，现在可能因为 AI 的介入而变得可行。

启示二：开发者的核心能力从"写代码"变成"设计系统"

当 AI 能高吞吐量生成代码时，开发者最重要的能力变成了：

• 设计清晰的类型系统和边界
• 写出可被 AI 执行的迁移规则
• 构建能让错误尽早暴露的测试和 CI 体系
• 判断 AI 输出的可信度和适用边界

启示三：AI 参与大型工程，是新手的危险区

一个初级开发者，如果让 AI 帮忙写一个 1000 行的函数，可能得到看起来正确但实际有 bug 的代码——因为初级开发者没有能力识别错误。

但一个资深系统程序员，让 AI 帮忙把 10 万行 Zig 代码翻译成 Rust——即使 AI 翻译得不太理想，工程师仍然能识别出哪里有问题、哪里需要调整。

AI 不会替你承担生产责任。它可以写代码、翻译代码、跑一轮 review，但架构边界、发布节奏、兼容性判断、线上问题的责任，仍然在人这边。

六、性能分析：Bun-Rust 的基准测试真相

6.1 官方基准测试结果

Bun 团队公布的官方 benchmark 数据：

"持平到更快"听起来像是保守表述，但实际上这是真实的结果。Bun 的性能瓶颈从来不在于语言本身，而在于：

• JavaScriptCore 引擎的执行效率（两种版本完全相同）
• 系统调用的开销（Rust 和 Zig 在这个层面差异不大）
• I/O 和网络库的效率（两者调用的 C 库相同）

Rust 版本带来的主要收益是：

1. 二进制体积缩小：Rust 的优化器在某些路径上生成更紧凑的代码
2. 内存分配更高效：Rust 的 allocator 生态比 Zig 更成熟
3. 长期性能稳定性：减少了内存泄漏和碎片化问题

6.2 为什么性能没有显著提升

这可能会让一些人失望：Bun-Rust 并没有因为 Rust 的"高性能"标签而获得数量级提升。

这是因为 Bun 的工作负载（JS 执行、网络 I/O、文件 I/O）中，语言级优化的空间本来就不大。真正占主导的是：

• JS 引擎的执行效率（两者共享 JavaScriptCore）
• 系统调用和网络 I/O 的开销（两者都通过 C 库）
• 内存分配策略（Rust 有优势但不是数量级）

类似地，Rust 在 WebAssembly 项目中的性能优势主要来自"避免 GC 停顿"，而不是"比 C++ 快"。

6.3 性能不是这次迁移的核心驱动力

回顾 Jarred 的表态，他说得很清楚："我们希望拿到 Rust 编译器和工具链对内存问题的辅助。"

性能是额外收益，但不是目标。真正节省的是开发和调试时间——一个在 Zig 中需要花 3 天调试的内存 bug，在 Rust 中可能直接被编译器拦截，或者通过 Miri 工具在测试阶段就被发现。

七、Bun 收购后对 AI 工具链的影响

7.1 Anthropic + Bun：战略协同

Anthropic 收购 Bun 的逻辑并非财务投资，而是战略整合：

• Claude Code 需要快速执行环境：Claude Code 在用户机器上执行 shell 命令、运行脚本、安装依赖——每一个操作的毫秒延迟都会影响用户体验
• Bun 的性能优势直接转化为 Claude Code 的速度优势：冷启动快 4-6 倍、包安装快 100 倍，这些数字在 Claude Code 的场景下就是真实的响应延迟
• 统一的工具链：Bun 集运行时、包管理器、bundler、test runner 于一体，Claude Code 可以直接依赖这个统一工具链

7.2 AI 辅助工程的新范式

Bun 迁移中 AI 的深度参与，代表了一种新的工程范式：

传统模式：
需求 → 设计 → 编码 → 测试 → 部署（人工主导全流程）

AI 辅助模式：
规则定义（人） → AI 批量生成（AI） → 工具约束验证（编译器/CI） 
→ 人工审查关键路径（人） → 测试套件保障（工具+人）

在这个新范式中：

• 规则文档变得和代码一样重要：好的 PORTING.md 比 1000 行 AI 生成的代码更有价值
• 测试覆盖率决定了 AI 的安全边界：测试越完善，AI 越不容易破坏已有行为
• 工程师的品味体现在系统设计上：不是代码写得多漂亮，而是系统架构多清晰

八、软件开发者的应对策略

8.1 如果你是 JavaScript/TypeScript 开发者

Bun 的 Rust 迁移对你没有直接影响。Bun 的 API 保持稳定，TypeScript 开发者编写的代码不需要任何改变。

但你应该关注的是：

• Bun 的工具链成熟度正在快速提升（HTTP 路由、数据库驱动等）
• Claude Code 集成了 Bun 作为底层，你在 Claude Code 中的每一次 bun install 都受益于此
• JavaScript 生态的基础设施正在被 Rust 重写：esbuild（Go）、SWC（Rust）、Bun（Rust）——这意味着 JS 生态的工具链正在变得更高效

8.2 如果你是系统程序员或对 Rust 感兴趣

Bun 迁移提供了一个教科书级别的案例，展示了：

• 如何将一个大型系统从一门语言迁移到另一门
• 如何用 AI 辅助工程迁移并保持工程质量
• Rust unsafe 的真实分布和降 unsafe 的实践方法
• FFI 边界处理、生命周期表达、跨语言对象管理的工程经验

建议你直接阅读：

• oven-sh/bun PR #30412
• Bun 仓库的 docs/PORTING.md
• Bun 的 unsafe 审计报告（仓库中有相关文档）

8.3 如果你是技术决策者

Bun 的案例告诉你：AI 辅助大型工程迁移的可行性边界已经大幅扩展。以前因为人力成本不敢评估的技术债务，现在可以认真考虑。

但同时也要清醒认识到：AI 能降低迁移的初始成本，但不会消除架构判断、风险评估、兼容性保障等需要人工专业判断的工作。

适合 AI 辅助迁移的项目特征：

• 边界清晰（有完善的测试覆盖）
• 规则可表达（PORTING.md 存在）
• 目标明确（迁移到 Rust/Go/Zig 等有成熟生态的目标语言）
• 规模可管理（单个模块 1-10 万行是 AI 辅助迁移的舒适区）

九、总结：这不是终点，而是开始

Bun 从 Zig 到 Rust 的迁移，是 2026 年软件开发领域最重要的工程实验之一。它的意义远超"Bun 换了语言"本身。

这件事告诉我们什么？

第一，AI 正在重新定义"大型工程"的可行性边界。 过去，因为人力成本而不敢触碰的迁移项目，现在有了新的评估框架。如果你有一个多年未动的 C++ 遗留模块，有一套想从 Ruby 迁移到 Go 的服务，现在可以认真评估 AI 辅助迁移的可行性。

第二，语言战争没有赢家。 Zig 和 Rust 都有自己的优势场景。Bun 团队选择 Rust，不是因为 Rust"赢了"，而是因为在这个特定场景下（长期维护、AI 辅助、生态成熟度），Rust 更适合。

第三，unsafe 本身不是问题，边界不清晰才是。 Bun 有 13,365 个 unsafe，但只要这些 unsafe 被集中在少数模块、边界清晰、有完整测试，它们就是可控的。真正危险的是 unsafe 散落在业务逻辑中、或者 safe API soundness 被破坏。

第四，开发者的角色在进化。 未来的优秀开发者，不是写得最快最多的那个，而是最会设计系统、最会写规则、最会判断 AI 输出质量的那个。

下一步值得关注

• Bun Rust 版本的 stable 发布（预计 2026 年 Q3-Q4）
• 迁移后长期内存安全数据的统计（miri 能否检测出真实 bug？）
• 生态影响：更多 JS 工具链是否会跟进 Rust 重写？
• AI 辅助迁移方法论的进一步成熟（是否有通用的迁移框架？）

参考资料：

• oven-sh/bun PR #30412 - Rewrite Bun in Rust
• Bun PORTING.md
• Bun unsafe audit report
• Anthropic 收购 Bun 公告（2025.12）

标签：Rust|Zig|Bun|JavaScript|TypeScript|AI编程|系统迁移|FFI|unsafe|内存安全

关键字：Rust重写|JavaScript运行时|Bun迁移|AI工程实践|Zig转Rust|unsafe代码审计|FFI边界|系统编程|TypeScript工具链|Anthropic