Bun 团队用 Rust 重写后发了份安全报告，一万多个 unsafe 看得我头皮发麻

先说结论：Bun 团队最近干了一件特别实在的事——他们把自己还没发布的 Rust 重写版本，翻了个底朝天，然后发了一份完整的安全审计报告。

报告里有个数字让我愣了一下：13,365 个 unsafe 代码节点，分布在 77 个不同的 crate 里。

我知道你看到这个数字的反应可能跟我一样——"这也太多了吧？"

但别急着下结论，这东西得掰开了聊。

unsafe 多就一定不安全？也不全是

如果你写过 Rust，应该知道 unsafe 关键字是用来干什么的——它告诉编译器："这块代码我自己担保安全，你别管了。"说白了就是手动内存管理，Rust 的"安全护盾"在那块代码上是暂时关掉的。

Bun 做的是一个 JavaScript/TypeScript 运行时，跟 Node.js 和 Deno 抢饭碗的那种。这种项目要跟底层操作系统打交道——文件 I/O、网络请求、系统调用——这些场景天然就需要 unsafe。你不碰底层，你就快不起来，而 Bun 主打的就是一个"快"。

所以啊，3 万行 Rust 代码里有 13,365 个 unsafe 节点，平均每两行半就有一个 unsafe——这个密度确实高得离谱。但换个角度看，能把这事公开说出来，本身就挺难得的。

这份审计报告不是 Bun 团队自己写的，而是找的第三方安全机构做的（虽然用了 AI 辅助）。报告发现的问题汇总一下大概是这么个情况：

严重级别的漏洞没几个，大部分是中等和低风险的问题。主要集中在内存安全边界处理上——比如某些场景下对用户输入的长度校验不够严格，某些 FFI（外部函数接口）调用没有正确处理错误返回值。

有意思的是，报告还提到了一些"设计层面的问题"——不是说代码写错了，而是某些架构决策本身就引入了不必要的 unsafe。换句话说，有些地方本来可以用安全 Rust 写，结果图省事直接上了 unsafe。

这就好比你说你要跑马拉松，结果每走两步就骑个摩托——那你还跑什么马拉松啊？

如果你是 Bun 的用户（或者正在考虑要不要用），我觉得这事反而是个好消息。

你想啊，一个团队愿意在自己产品还没正式发布之前，就花钱请人做安全审计，还把结果公开出来——这在开源社区里真的不多见。大多数项目的节奏是"先发布、再修 bug、出了安全问题再补丁"。

Bun 这种"先审计再发布"的做法，老实说，多少有点理想主义。但我喜欢这种理想主义。

另外，如果你也在用 Rust 写项目，这份报告其实是个很好的学习材料——你可以看看别人的 unsafe 都用在了什么地方，有没有什么坑是你自己也没注意到的。

说实话，我一开始看到那个一万多的数字，第一反应也是"卧槽，这项目是不是要翻车了"。但仔细看了几篇分析之后，我觉得没那么夸张。

unsafe 本身不是原罪，问题在于你用了 unsafe 之后有没有做足够的防护。Bun 团队在报告里也说了，后续会推动把一部分 unsafe 改写成安全 Rust，同时加强 unsafe 代码周围的边界检查。

这就像你家里装了把锁——锁本身不是问题，问题是你有没有养成随手锁门的习惯。

Bun 现在还在快速迭代阶段，从性能角度来看，它确实已经让人眼前一亮了。这次安全审计虽然暴露了一些问题，但也恰恰说明这个团队对质量的追求是认真的。

反正我个人的态度是：继续用，继续关注。等 Rust 重写版正式发布的时候，我肯定第一时间升级。