Bun 用 Rust 重写，最值钱的不是快，是先把坑翻出来

⚠️ 这条是写给只会用聊天型大模型、最近开始想跟进 AI 新工具的普通人。你刚刷到这条消息，本来准备顺手划走，但又怕自己错过了真正会影响下一步判断的那一点。最容易做错的第一步，就是把它当成一次“更快了”的技术热闹。

如果只盯表面热闹，你很容易在错误方向上花掉时间、预算和注意力。更隐性的代价，是你会一直围着表面热闹转，却看不到“Rewriting Bun in Rust”真正改变的那一步。[C001] 我后来才改观：一条更新值不值得看，不看它列了多少功能，先看它会不会改掉你下一步的判断。Rust 对 Bun 最大价值，是把未定义行为显影，也就是表面能跑、底层随时可能出错的那种坑。[C002]

那句英文标题 Rewriting Bun in Rust，说白了就是“用 Rust 重写 Bun”。[C001] 真让我改观的，不是标题，而是两个很具体的动作。

第一，官方在修 WeakPtr、ObjectPool、JSON tape 这 3 个底层模块时，直接跑 bun run rust:miri。Miri 可以理解成专门揪内存问题的检查工具，这一次就抓出 7 处未定义行为，还顺手封掉了 NonNull::from(&*x) 这类危险写法。[C003] 这不是“代码更漂亮”而已，而是以前靠经验压着不爆的问题，现在终于能被反复抓出来。

第二，项目总配置文件 Cargo.toml 里，把 undocumented_unsafe_blocks、not_unsafe_ptr_arg_deref、warnings 这些规则都设成 deny，白话就是：只要碰到这类安全边界，代码就别想混过去。[C004] 说白了，不再赌作者今天有没有想起来，而是先把高风险写法拦在门口。

所以这条消息适合两种人。第一种，是没空啃源码、但又怕跟错方向的人：别只看快不快，先看它有没有把坑翻到台面上。第二种，是正在做重写或迁移的人：先别急着喊性能提升，先想办法把隐患变成能检查、能复现、能提工单的问题。

边界也得说清：现有证据主要来自 Bun 官方提交和仓库配置，不是独立跑分实测；它能说明“风险更容易被发现”，不能说明“Rust 会自动修好所有坑”。如果你身边也有人总被“更快”“更强”带着跑，把这条转给他；下次再刷到新工具更新，先问一句：它只是更热闹了，还是把坑真的翻出来了？