GitHub commit 46d3bc2，标题是 docs: add Phase-A porting guide。标题很轻，内容不轻：Bun 仓库新增 docs/PORTING.md，约 576 行，写的是 Zig→Rust 的 Phase A 迁移规则。

这不是“Bun 已经 Rust 重写完成”。目前能确认的事实更窄：仓库里出现了一套把 Zig 文件逐个翻成同目录 Rust 草稿的指南和脚本。

真正值得看的是反常点：Bun 往 Rust 迁，却明确不吃 Rust 常见全家桶。它要 Rust，但不要 tokio、hyper、futures、async fn，也不要 std::fs、std::net、std::process。

这说明事情不是简单的“Rust 赢了，Zig 输了”。更像是一个高性能基础设施项目长大后，开始重新计算维护成本。

这次提交改变了什么

这份指南把迁移拆成两步：Phase A 先翻译，Phase B 再落地编译。

事项文档规则现实含义
Phase A在 .zig 旁边生成同名 .rs 草稿先捕捉逻辑，不要求可编译
Phase Bcrate-by-crate 编译再处理 Cargo、类型、性能和工程落地
审查方式保留 Zig 结构、函数名、字段顺序、控制流方便 Zig/Rust 并排 diff
Rust 生态不引入 tokio、rayon、hyper、futures，不用 async fn不是拥抱标准 Rust 异步栈
I/O 路线不用 std::fs、std::net、std::processBun 仍想保留自有事件循环和 syscall 体系

Phase A 的目标很克制：忠实翻译，不追求漂亮，不追求编译通过。

这点很关键。它把“迁移”从一次架构豪赌，降级成一组可审查的机械动作：同目录、同结构、同控制流，先让人能对着看。

对 Bun 贡献者来说，短期变化不是“马上写 Rust 版 Bun”，而是审查方式变了。以后判断一段 Rust 草稿对不对，核心不是它像不像惯用 Rust，而是它有没有保住 Zig 原逻辑。

对运行时和工具链开发者来说，这份文档更像样板：大型底层项目迁语言，第一步不是炫技，而是把语义损耗压到最低。

普通 Bun 用户短期不必因为这个提交改项目。材料里没有迁移时间表，也没有性能数据，更没有说明现有 Bun 行为会立刻变化。现在该做的是观望，不是恐慌升级或迁出。

真正的信号：语言选择开始变成组织账本

我不太买账“Rust 先进，所以 Bun 投奔 Rust”这种说法。

如果 Bun 真是全面拥抱 Rust 范式，它不会在迁移指南里同时拒绝 tokio、hyper、futures、async fn 和标准库 I/O。它保留自有事件循环和 syscall 体系，说明底层控制权仍然很重要。

所以这次迁移更像一笔工程账。

Zig 对早期 Bun 很合适。直接、锋利、控制感强。一个高性能工具链项目在早期靠少数强人推进，语言越贴近底层，越容易把性能和表达压到极限。

但项目长大后，问题会换。

你需要更多贡献者。你需要更稳定的 review。你需要新人能看懂边界。你还需要错误处理、生命周期、模块拆分和依赖管理能被团队反复讨论，而不是只靠核心作者脑内缓存。

这时语言不只是“能不能写快”。它还要回答：谁能接手，谁能审，谁能招，谁能长期维护。

“天下熙熙，皆为利来。”放在这里，这个“利”不是一句商业鸡汤。它是招聘半径、审查成本、生态工具、IDE 支持、CI 习惯，以及贡献者愿不愿意把周末投进来。

Zig 没必要被写成失败者。材料也支撑不了这个结论。

更稳的判断是：Bun 的规模化维护压力，正在改变语言成本结构。Zig 仍有技术价值，但 Rust 在多人协作、生态惯性和工程审查上的账面优势，开始变得更难忽略。

这对押注 Zig 生态的开发者会有心理冲击。尤其是那些把 Bun 当作 Zig 代表性工程样本的人，会重新评估一个问题：Zig 的优势能不能撑过项目从先锋期到维护期的那道坎。

企业采用者也会更谨慎。不是因为 Bun 不能用，而是因为底层语言路线进入迁移准备期。对保守团队来说，合理动作不是立刻弃用，而是延后把 Bun 放进关键链路，等 Phase B 是否真的开始 crate-by-crate 编译、测试和发布策略更清楚。

接下来只看三个变量

这件事最容易被吵成语言战争。那是低效读法。

真正该看的变量很具体。

观察点为什么重要
Phase B 何时出现实质性 crate 编译Phase A 只是草稿，Phase B 才进入工程成本结算
Rust 草稿是否长期保持与 Zig 并行如果长期双轨，维护成本可能先升后降，甚至不降
Bun 是否继续拒绝 tokio/std I/O/async fn这决定它是在借 Rust 工具链，还是逐步靠近 Rust 主流生态

第一个变量决定迁移是否真的向产品推进。现在只能看到 Phase A 指南，不能据此断言 Rust 版 Bun 已经成形。

第二个变量决定贡献者负担。如果 Zig 和 Rust 长期并排存在，review 会更重，代码同步也会更痛。迁移不是免费午餐，双轨期尤其贵。

第三个变量最能看出 Bun 的真实取舍。它现在的姿态很清楚：拿 Rust 的工程外壳，但不交出底层调度权。

这和很多技术史里的路径相似，但不完全一样。铁路、电力、互联网平台早期都靠冒险者开路；网络一旦变大，调度、标准和维护纪律就开始压过个人胆识。软件项目也会走到这一步。

Bun 这份文档最有意思的地方，是它没有把迁移包装成神话。

它讲文件位置，讲字段顺序，讲控制流，讲 diff 审查。很枯燥，但可信。大型工程真正要命的地方，往往就在这些枯燥处。

锋利语言能帮项目冲出第一段路。可一旦进入长期战，项目要靠普通工程师反复接手、审查、修改、发布。到那时，代码不只是作品，也是资产。

Bun 现在做的，不是给 Zig 判死刑，也不是给 Rust 加冕。它是在给自己的代码资产找一套更能协作、更能审查、更能长期交接的容器。

这一步不浪漫。也不轻松。

但它很像成熟项目会做的选择：先把天才写法，翻译成团队能接班的工程语言。