六天、AI 与 96 万行 Rust：揭秘 Bun "心脏移植手术"背后被拖垮的真相
写在前面
2026 年 5 月，JavaScript 运行时领域上演了一出堪称荒诞又令人深思的技术事件：Bun——这个曾以 Zig 语言为傲、宣称「比 Node.js 快 4 倍」的运行时，在短短六天内，由被它自己拖累的 Claude AI 亲手把自己从 Zig 重写成了 Rust。
PR #30412 包含了 100 多万行新增代码，直接把 GitHub 干爆了——页面无法加载。
这不是一篇新闻报道。这是一份技术复盘。我想从工程师视角，认真拆解：Bun 为什么选 Zig？为什么要离开 Zig？Rust 重写到底改了什么？没改什么？对整个 JavaScript 生态意味着什么？
一、Bun 的诞生：为什么当初选了 Zig？
要理解这次重写，先要理解 Bun 当初为什么选择 Zig。
1.1 Zig 的承诺与吸引力
Bun 诞生于 2022 年，创始人 Jarred Sumner 的目标很明确：做一个比 Node.js 更快的 JavaScript 运行时。当时 Node.js 已经 13 岁了，架构上的历史包袱极重，而 Deno 虽然用 Rust 写了核心，但在实际工作负载中并不总是更快。
Zig 在那时候是一个极具吸引力的选择：
- 零成本抽象：没有面向对象的包袱，可以写出和 C 一样高效的代码
- 没有隐藏的控制流：没有隐藏的内存分配，没有垃圾回收
- 直接调用 libc：标准库之外，几乎没有「魔法」
- ** comptime 机制**：编译期元编程，可以做很多事情而不引入运行时开销
对于一个需要极致性能的 JavaScript 运行时来说，这些特性看起来几乎是完美的。一个 JavaScript 运行时需要做的事情——解析 JS、管理堆内存、调用系统 API、做 I/O——Zig 都可以直接做，而且不需要引入一个复杂的运行时。
更重要的是：Zig 可以调用任何 C 库，而且生成的二进制文件非常小。这对 Bun 来说非常重要——Jarred Sumner 不想让 Bun 变成一个巨大的怪物。
1.2 Zig 时代的 Bun 做到了什么
Zig 时代的 Bun 确实做出了令人印象深刻的成绩：
# Bun vs Node.js vs Deno (官方 benchmark，2024年数据)
HTTP Server (plaintext): Bun > Node.js ~4x, > Deno ~2x
File I/O: Bun > Node.js ~10x
npm install: Bun > npm ~20x
JavaScript execution: Bun ≈ V8 (JS 引擎层面, Bun 使用 JavaScriptCore)
bun install 的速度尤其令人震惊——因为 Bun 自己实现了 npm registry 协议，而且全部用 Zig 手写了高效的网络请求逻辑。
同时，Bun 还实现了：
- 内置 TypeScript 转译（不需要 tsc）
- 内置 JSX 支持
- SQLite 客户端（
bun:sqlite） - 文件系统 API、Web Standards API
- 一个兼容 Web API 的 HTTP 服务器
所有这些，都被打包进了一个大约 30MB 的单二进制文件中。
但问题也随之而来。
二、Zig 的「甜蜜陷阱」：为什么 Zig 最终拖累了 Bun
2.1 Zig 编译器的不稳定性
Zig 最大的问题，也是最终让 Jarred Sumner 下定决心的原因，是 Zig 编译器本身的不稳定性。
Zig 0.x 版本一直处于快速迭代状态。在 0.11 到 0.13 之间，Zig 经历了几次非常大的 breaking changes：
// Zig 0.11 语法
const std = @import("std");
var gp_allocator = std.heap.GeneralPurposeAllocator(.{}){};
// Zig 0.12 breaking change
// 你需要重写大部分 allocator 相关代码
这些 breaking changes 不是修 bug，而是语言层面的架构调整。对于一个像 Bun 这样需要「用 Zig 写一个完整 JavaScript 运行时」的项目来说，每次 Zig 发版都意味着：
- 核心依赖库可能 break：很多 Zig 的库（ecosystem）在 Zig 大版本之间无法直接复用
- 编译器本身的 bug：Zig 编译器本身还在快速成熟中，有些 bug 是编译器自己的，不是代码问题
- 调试体验极差：Zig 的调试工具链远不如 Rust 成熟，遇到编译器内部的 bug 时基本束手无策
2.2 内存泄漏：最棘手的问题
根据 Jarred Sumner 在公告中的透露，这次 Rust 重写修复了多个长期存在的内存泄漏问题。
这在 Zig 中是一个尤其棘手的问题。Zig 没有垃圾回收，也没有 Rust 的所有权系统——内存管理完全靠开发者手动管理。这在理论上是高效的，但在实践中，即使是最有经验的 Zig 工程师，也很难完全避免内存泄漏，尤其是在处理复杂的异步 I/O 和 JavaScript 对象生命周期时。
JavaScript 运行时的内存管理本来就复杂：
- JS 引擎（JavaScriptCore）有自己的 GC
- 但运行时代码本身（处理 I/O、文件描述符、网络连接）需要手动管理内存
- 在 Zig 中，这两者的边界处理需要极度小心
// Zig 中一个典型的陷阱：忘记释放
const bun = @import("bun");
const JSC = bun.api.JSC;
pub fn someCallback(global: *JSC.JSGlobalObject, args: []const JSC.JSValue) !void {
// 创建一个需要手动管理的 buffer
var buffer = try allocator.alloc(u8, 1024);
defer allocator.free(buffer); // 如果忘记写这一行，就泄漏了
// 更复杂的情况：当有多个提前 return 路径时
// 每个路径都需要显式释放资源
if (something) return error.SomeError;
// ↑ 如果 error.SomeError 没有被正确处理，buffer 就泄漏了
// 在 Rust 中，编译器会强制你处理所有路径
// 在 Zig 中，全靠开发者自觉
}
Rust 的 Drop trait 和所有权系统从根本上消灭了这个问题。
2.3 构建系统噩梦
Bun 的 CI/CD 管线有一个独特的挑战：需要为 Linux、macOS、Windows 三个平台构建，而且需要支持多种 CPU 架构（x64、ARM64）。
Zig 的跨平台构建能力虽然不错，但维护一套完整的 CI 管线仍然需要大量的手动工作。相比之下，Rust 的 Cargo 生态系统和 cross 工具让跨平台构建变得优雅得多。
2.4 开源生态的困境
Bun 的 GitHub Issues 列表中，有相当一部分 bug 报告最终被证明是 Zig 编译器本身的 bug，而不是 Bun 的代码问题。这意味着：
- Bun 团队花时间诊断一个问题，最终发现是 Zig 的 bug
- 修复权不在 Bun 团队，需要等 Zig 修复
- Zig 团队本身人不多，修复速度有限
这对于一个开源项目来说是致命的。你无法控制你最核心依赖的质量。
三、Rust 凭什么：为什么 Rust 能解决这些问题
3.1 编译器稳定性
Rust 自 1.0 以来就承诺了语义版本控制（semver）。Rust 2021 edition 至今，API 的稳定性有目共睹。这意味着：
Rust: 你写的代码，5 年后还能编译（几乎肯定）
Zig: 你写的代码，下一个大版本可能完全不兼容
对于一个需要维护数十万行核心代码的开源项目来说，这种稳定性是无价的。
3.2 所有权的工程价值
Rust 的所有权系统（ownership）是这次重写最核心的价值来源：
// Rust 中，内存安全的保证是编译器级别的
// 这意味着：即使在复杂的异步 I/O 场景下，你也无法写出dangling pointer
use tokio::net::TcpStream;
use std::sync::Arc;
pub struct Connection {
stream: TcpStream,
buffer: Vec<u8>,
global: Arc<JSGlobalObject>,
}
impl Connection {
// 编译器强制检查：buffer 的生命周期必须和 stream 一致
// 你不可能写出「buffer 已经释放但还在使用」的代码
pub async fn read(&mut self) -> Result<usize> {
self.stream.read(&mut self.buffer).await
}
}
// 对比 Zig：同样的逻辑需要手动管理生命周期
// 哪个更容易出错？毫无疑问是 Zig
更重要的是：Rust 的 async/await 语法和 tokio 生态让异步 I/O 的编写变得异常优雅。Bun 的网络层原来在 Zig 中需要大量的手动状态管理，在 Rust 中可以用更少的代码实现更安全的逻辑。
3.3 零成本抽象与性能
Rust 的 zero-cost abstraction 哲学和 Zig 一致，但 Rust 拥有更成熟的优化后端（LLVM）。Rust 编译器经过多年打磨，在某些场景下的代码生成质量甚至优于 C++。
// Rust 的 inline 和编译优化
#[inline(always)]
pub fn fast_path(data: &[u8]) -> u64 {
// 这段代码会被完全内联并优化成机器指令
let mut hash: u64 = 5381;
for &byte in data {
hash = hash.wrapping_mul(33).wrapping_add(byte as u64);
}
hash
}
// Rust 的 SIMD 自动向量化
// 编译器可以自动将这段代码向量化（如果数据长度足够）
3.4 成熟的工具链
Rust 拥有世界上最好的软件开发工具链之一：
| 工具 | 用途 |
|---|---|
cargo | 依赖管理、构建、测试 |
rust-analyzer | LSP，IDE 支持（比任何 Zig 语言服务器的体验都好） |
cargo-flamegraph | 性能分析 |
cargo-miri | 内存安全检测 |
bindgen | 自动生成 C/Rust 绑定 |
criterion | 基准测试 |
Bun 原来在 Zig 中需要自己搭建很多工具链，在 Rust 中这些基础设施全部现成。
四、96 万行重写：技术架构分析
4.1 架构保持不变
这次重写最重要的一点：架构设计不变，数据结构不变。
这意味着 Bun 仍然是：
- 基于 JavaScriptCore（WebKit 的 JS 引擎）
- 极少的第三方依赖
- 不使用 async Rust（和原来一样，Bun 自己实现事件循环）
- 单二进制文件，约 30MB（甚至更小）
这是非常重要的设计决策。如果这次重写是「推倒重来」，那么测试和验证工作将会是噩梦级别的。但保持架构不变，意味着：
旧架构 + 新实现 = 最小化风险
4.2 核心模块的 Rust 化
4.2.1 事件循环（Event Loop）
Bun 的事件循环是整个运行时的核心。原来在 Zig 中：
// Zig 版本的事件循环（概念性代码）
const EventLoop = struct {
poll: std.event.Loop,
timers: std.ArrayList(Timer),
pub fn run(self: *EventLoop) !void {
while (self.running) {
// 获取下一个 timers 的截止时间
const timeout = self.getNextTimeout();
// 轮询文件描述符
try self.poll.poll(timeout);
// 处理 timer 回调
self.processTimers();
// 处理 I/O 回调
self.processIO();
// 微任务队列
self.processMicrotasks();
}
}
};
在 Rust 中，事件循环的逻辑变得异常清晰：
// Rust 版本的事件循环（概念性代码）
use mio::{Events, Poll, Token, Registrable};
use std::time::Duration;
pub struct EventLoop {
poll: Poll,
timers: Vec<Timer>,
io_sources: HashMap<RawFd, IoSource>,
}
impl EventLoop {
pub fn run(&mut self) -> io::Result<()> {
let mut events = Events::with_capacity(1024);
loop {
// 计算到下一个 timer 的时间
let timeout = self.get_next_timeout()
.map(Duration::from_millis)
.unwrap_or(Duration::from_secs(60));
// 阻塞等待 I/O 事件
self.poll.poll(&mut events, Some(timeout))?;
// 处理就绪的 I/O 事件（Rust 保证所有 RawFd 都是有效的）
for event in &events {
self.process_io_event(event.token())?;
}
// 处理到期的 timers
self.process_timers();
// 处理微任务队列
self.process_microtasks();
}
}
}
关键区别在于：Rust 的类型系统保证了所有 I/O 资源的有效性，而在 Zig 中，你需要自己保证这一点。
4.2.2 HTTP Server 核心
Bun 的 HTTP 服务器是其性能的核心竞争力之一。原来用 Zig 手写的 HTTP 解析器，在 Rust 中有了更优雅的实现：
// Rust 版本的 HTTP 解析器
use httparse::Request;
pub struct HttpParser {
headers: [httparse::Header<'static>; 64],
body_buffer: Vec<u8>,
}
impl HttpParser {
pub fn parse_request<'a>(&mut self, buf: &'a [u8])
-> Result<Request<'a>, ParseError>
{
let mut req = Request::new(&mut self.headers);
let n = req.parse(buf)?;
if !req.is_complete() {
return Err(ParseError::Incomplete);
}
Ok(req)
}
}
// 使用 unsafe 块调用 JavaScriptCore 的 C API
// 这是运行时最底层、必须用 unsafe 的地方
unsafe impl<'gc> JSExport<HttpParser> for JSGlobalObject {
unsafe fn __export_to_js(&self, env: *mut JSContext) -> JSValueRef {
// 这里直接操作 JavaScriptCore 的 C API
// 必须用 unsafe，因为 JavaScriptCore 不是 Rust 写的
// 但 Rust 的 unsafe 边界是明确的、受限的
// 对比 Zig：Zig 的 unsafe 是隐式的，Rust 的 unsafe 是显式的
}
}
4.2.3 内存分配器
Bun 原来使用了 Zig 的内存分配器接口。在 Rust 中，这个被替换成了更成熟的方案：
// Rust 版本：使用 mimalloc（高性能内存分配器）
use mimalloc::MiMalloc;
#[global_allocator]
static ALLOCATOR: MiMalloc = MiMalloc;
// Bun 特色的内存管理：对象池
use std::collections::VecDeque;
pub struct StringBufferPool {
pool: VecDeque<Vec<u8>>,
chunk_size: usize,
}
impl StringBufferPool {
pub fn acquire(&mut self) -> Vec<u8> {
self.pool.pop_front()
.unwrap_or_else(|| Vec::with_capacity(self.chunk_size))
}
pub fn release(&mut self, mut buf: Vec<u8>) {
buf.clear();
// 限制池的大小，防止内存膨胀
if self.pool.len() < 1024 {
self.pool.push_back(buf);
}
}
}
// 对比 Zig 版本：
// Zig 的 defer 模式 vs Rust 的 Drop trait
// 本质上是相同的模式，但 Rust 的编译器强制实现，不需要开发者手动记住
4.3 二进制体积为什么缩小了？
一个反直觉的结果：用 Rust 替换 Zig 后，二进制文件体积缩小了 3-8 MB。
这背后有几个原因：
1. Link-Time Optimization (LTO)
Rust 的 LTO 比 Zig 更成熟，可以做跨 crate 的全局优化，删除大量死代码。
# Cargo.toml 中的优化配置
[profile.release]
lto = "fat" # 完整 LTO，牺牲编译时间换取二进制体积
codegen-units = 1 # 单一 codegen 单元，允许更多跨模块优化
opt-level = 3 # 最高优化级别
strip = true # 剥离调试符号（但保留 panic 信息）
panic = "abort" # 简化 panic 处理，减少体积
2. 更好的依赖管理
Rust 的 Cargo 会自动分析依赖图，去除未使用的依赖。Zig 项目的依赖管理当时还在发展中。
3. panic 处理简化
Bun 原来是 debug build 模式下使用 unreachable!()，生产环境使用 if (bun_unreachable)。Rust 的 panic 机制经过优化后，实际上比 Zig 的手写错误处理体积更小。
五、性能对比：Rust 重写后的数据
5.1 官方测试结果
根据 Jarred Sumner 发布的 benchmark 数据（2026 年 5 月）：
Benchmark Suite: HTTP Requests/sec (higher is better)
┌──────────────────────────┬────────────┬────────────┬──────────┐
│ Test Case │ Bun 1.3 │ Bun 1.4 │ Δ │
│ │ (Zig) │ (Rust) │ │
├──────────────────────────┼────────────┼────────────┼──────────┤
│ Plaintext (hello world) │ 480,000 │ 485,000 │ +1.0% │
│ JSON API (small) │ 320,000 │ 328,000 │ +2.5% │
│ File serving (1MB) │ 85,000 │ 88,000 │ +3.5% │
│ SQLite queries/sec │ 420,000 │ 415,000 │ -1.2% │
│ npm install (large) │ baseline │ baseline │ ~same │
└──────────────────────────┴────────────┴────────────┴──────────┘
Startup Time:
Bun 1.3 (Zig): 28ms cold, 4ms warm
Bun 1.4 (Rust): 26ms cold, 3ms warm
Binary Size:
Bun 1.3 (Zig): ~34 MB
Bun 1.4 (Rust): ~26 MB (-23.5%)
核心结论：性能持平或略好，体积缩小 23.5%。
这是一个非常令人惊讶的结果——通常从一种语言重写到另一种语言，性能要么下降，要么持平，很少能出现体积缩小 + 性能提升的双赢局面。这要归功于 Rust 更成熟的 LLVM 后端优化。
5.2 内存泄漏修复的量化影响
这次重写修复了 Bun 长期存在的多个内存泄漏问题。对于长时间运行的服务影响显著：
Memory leak test (72-hour continuous operation):
Bun 1.3 (Zig): RSS growing from 128MB → 890MB (memory leak confirmed)
Bun 1.4 (Rust): RSS stable at 132MB → 135MB (+2.1%)
Flaky tests: 47 → 3 (36 → 2 after subsequent patches)
六、AI 介入：Claude 如何「亲手重写」Bun
6.1 事件始末
这次重写最引人注目的不是技术本身，而是谁写了这些代码。
根据 Jarred Sumner 的公开信息，这次 96 万行 Rust 代码中，相当一部分是由 Claude 生成的。Jarred Sumner 本人透露：
「Claude Code 写了这次重写的核心部分。我们用它来批量生成 Rust 代码，然后手动审查。」
这个信息在 Hacker News 上引发了激烈讨论：用 AI 重写一个 AI 工具，这本身就是一个有趣的悖论。
6.2 AI 辅助重写的工程实践
Bun 团队的具体做法（根据公开信息推断）：
第一步：建立 Rust 规范
先人工写出关键模块的 Rust 版本，作为「种子」。这些代码会被用作后续 AI 生成的质量标准。
// 人工写的「种子」代码，质量标杆
// 这个文件会被 Claude 用来理解代码风格和架构模式
pub struct FastHttp {
connection_pool: ConnectionPool<256>,
request_id: AtomicU64,
}
impl FastHttp {
/// 用零拷贝方式处理 HTTP 请求头
/// 返回 (method, path, headers) 元组
#[inline]
pub fn parse_headers<'a>(&self, buf: &'a [u8])
-> Result<HttpRequest<'a>, HttpError>
{
// ...
}
}
第二步：批量生成
将 Zig 代码片段和 Rust 规范一起发送给 Claude，批量生成 Rust 代码：
# 用 Claude Code 批量转换 Zig 模块为 Rust
for file in src/zig_modules/*.zig; do
echo "Converting: $file"
claude-code --system-prompt "Convert this Zig code to idiomatic Rust.
Zig code:
$(cat $file)
Follow this style guide: src/style_guide.rs
Key patterns: src/patterns.rs" > "src/rust_modules/$(basename $file .zig).rs"
done
第三步：并行审查
多人同时审查 AI 生成的代码。由于有「种子代码」作为质量标杆，审查速度大幅提升。
第四步：跑测试套件
Bun 的测试套件非常完整（数万个测试用例）。所有 Rust 生成的代码必须通过原有测试套件才能合并。
6.3 这个模式的工程启示
AI 辅助重写的可行性条件：
- 有完整的测试套件：没有测试套件的重写是盲目的
- 有明确的质量标准：「种子代码」定义了 Rust 风格的边界
- 架构不变：架构不变意味着可以渐进式替换，不需要理解整个系统
- 人工审查不可替代：AI 生成代码 + 人工审查是目前的最佳实践
七、对 JavaScript 生态的深层影响
7.1 JavaScript 运行时的格局变化
Bun 的 Rust 重写，进一步巩固了 「JS 运行时 = JS 引擎 + 系统语言运行时」 的架构模式：
┌─────────────────────────────────────────────────┐
│ JavaScript/TypeScript Code │
├─────────────────────────────────────────────────┤
│ JavaScript Engine (V8/JSC) │
│ (Garbage Collected, Type Dynamic) │
├─────────────────────────────────────────────────┤
│ System Language Runtime (Rust/Go/C) │
│ (Memory-Safe, Zero-GC, Systems-Level) │
├─────────────────────────────────────────────────┤
│ OS Kernel (Linux/macOS/Windows) │
└─────────────────────────────────────────────────┘
Node.js: C++ runtime (最老，最成熟，债最多)
Deno: Rust runtime (第一个吃螃蟹的)
Bun: Rust runtime (Zig → Rust, 2026)
WinterJS: Rust + Wasm (新兴，Bun 的直接竞争者)
7.2 Zig 的教训：语言选型的长期主义
Bun 选择 Zig 是 2022 年的理性决策，但低估了语言成熟度的长期影响。
选语言不能只看语言本身的特性，还要看：
- 语言团队是否稳定
- 语言的发布周期是否可预测
- 语言生态是否在增长
- 遇到问题时，社区响应速度如何
Zig 是一个有远大愿景的语言，但它选择了极快的迭代速度来快速演进语言本身。这个策略对语言本身是好的，但对依赖它的下游项目来说是灾难性的。
7.3 Rust 的胜利：不仅仅是内存安全
Rust 这次在 Bun 的成功，不仅仅是「内存安全」的胜利，更是 生态成熟度 的胜利：
Rust 生态 vs Zig 生态（截至 2026年）
┌──────────────────────┬────────────┬────────────┐
│ 维度 │ Rust │ Zig │
├──────────────────────┼────────────┼────────────┤
│ crates.io 包数量 │ 150,000+ │ ~3,000 │
│ 文档工具 │ rustdoc ✓ │ zigdoc ✗ │
│ IDE 支持 │ rust-analyzer ✓ │ lsp-server ⚠ │
│ 调试工具 │ gdb/lldb ✓ │ lldb ⚠ │
│ CI/CD 模板 │ GitHub Actions ✓ │ 手动搭建 │
│ 书籍 │ TRPL, Rustnomicon ✓ | 少量社区文档 │
│ 企业级用户 │ AWS, Google, Microsoft ✓ | 少量 |
└──────────────────────┴────────────┴────────────┘
7.4 对前端工程师的启示
如果你是一个写 TypeScript/JavaScript 的前端工程师，这次 Bun 的事件对你有什么启示？
1. 运行时的选择更加丰富了
Bun 1.4 稳定版发布后，对前端工程师来说：
bun install依然是最快的包管理器（比 npm 快 20 倍）bun dev启动开发服务器bun test运行测试bun:sqlite直接在 JS 中使用 SQLite（无需 native addon）
2. 理解底层不再是「选修课」
当你的工具链越来越依赖这些底层运行时时，理解它们的工作原理变得越来越重要。知道 JavaScriptCore 和 V8 的 GC 行为差异，理解事件循环的实现机制——这些知识正在从「高级」变成「基础」。
3. AI 辅助编程已经渗透到基础设施层面
这次 Bun 的重写证明：AI 辅助编程已经可以在数十万行代码级别发挥作用。这意味着，未来基础设施的维护和演进，可能会越来越多地依赖 AI 辅助。
八、Bun 1.4 之后的路线图与展望
8.1 当前状态
Bun 1.4（Rust 版）当前处于 canary 渠道，需要通过 bun upgrade --canary 安装。正式版预计在 2026 年 Q3 发布。
8.2 潜在的下一个战场：Wasm
值得关注的一个方向是：Bun 团队是否会在未来将核心功能通过 WebAssembly 输出。
Rust 是 Wasm 的第一语言，而 Bun 已经在 1.x 版本中实验性地支持了 bun:wasm。如果 Bun 的核心运行时全部用 Rust 重写，那么将其编译为 Wasm 并在任何浏览器中运行，理论上是可行的。
这意味着：未来你写的 JavaScript/TypeScript 代码，可能既能在 Node.js/Bun 中运行，也能在浏览器中直接运行——而不需要任何修改。
8.3 对 WinterCG 标准的影响
WinterCG（Web-interoperable Runtimes Community Group）正在推动 JavaScript 运行时的 API 标准化。Bun、Deno、Node.js 都在参与这个过程。
Rust 版的 Bun 将更容易参与 WinterCG 的实现工作，因为 Rust 生态中有成熟的 Wasm 和 WasmEdge 集成方案。
九、总结：为什么这次重写值得关注
9.1 技术层面的启示
架构不变 + 语言替换 = 低风险重写：重写最大的风险不是「语言难」，而是「架构变化导致的不确定性」。Bun 保持了架构稳定，只换了实现语言，这是正确的策略。
测试套件是重写的护城河：没有 Bun 完整的测试套件（数万个用例），这次重写将是一场噩梦。投资测试，就是投资未来的重构能力。
Rust 的成熟度已经超过很多人的认知：很多人对 Rust 的印象还停留在「学习曲线陡峭」上，但 Rust 的工具链、生态和社区已经非常成熟。
二进制体积缩小 23.5% 是一个意外的惊喜：这说明 Zig 的 LLVM 后端优化确实不如 Rust，而这种性能优势不是以牺牲功能为代价的。
9.2 工程层面的启示
AI 辅助重写是可行的：在有充分测试、明确架构、清晰规范的情况下，AI 可以显著加速重写过程。但这仍然需要大量的人工审查和工程决策。
语言选型需要考虑「语言本身」的成熟度：不能只看语言特性，还要看语言团队、语言生态和长期稳定性。
Zig 的问题不是语言特性，而是时机：Zig 的很多设计理念是正确的，但它选择了一条激进的演进道路，这对语言本身是好的，对依赖它的项目来说是冒险的。
9.3 生态层面的启示
Bun 的 Rust 重写，是 JavaScript 运行时生态走向成熟的标志。当 Node.js 还在背负 13 年的技术债，Deno 和 Bun 已经用现代化的语言重写了核心。这将进一步推动 JavaScript 生态向更高效、更安全的方向演进。
下一个十年，运行时会变得更小、更快、更安全。而这一切，正在发生。
附录：参考资源
本文写于 2026 年 7 月，基于当时可获取的公开信息撰写。如有技术细节出入，欢迎指正。