IT资源栈备受瞩目的高性能 JavaScript 运行时 Bun 日前公布了其未发布的 Rust 移植版本的详细审计报告。尽管目前用户安装的 Bun 版本仍基于 Zig 语言实现，但开发团队正在积极推进 Rust 版本的移植工作。此次针对特定提交代码（commit 3eb0fda021）的深度审计显示，该 Rust 移植版中存在高达 13,365 个 `unsafe` 代码块。审计报告通过自动化的 ripgrep 命令统计及人工分类，详细剖析了这些不安全代码的来源。结果显示，仅有 3% 的 unsafe 块是出于性能考量，绝大多数代码块源于 FFI（外部函数接口）边界处理以及从 Zig 代码库直接移植时沿用的所有权习惯。此外，审计还发现了 5 个目前尚未被发现的内存安全漏洞，这些是存在于安全 Rust 代码中的未定义行为。针对这 13,000 多个问题点，报告制定了详细的清理计划：预计约 9,300 个 unsafe 块可以被重构为安全的 Rust 代码，而约 4,000 个因涉及底层系统交互或 C/C++ 绑定而必须保持 unsafe 状态。报告还对比了 Bun 与 Deno 等其他运行时在 unsafe 代码密度上的差异，指出 Bun 将绑定层与运行时混合在同一工作区的模式导致了较高的代码密度。值得注意的是，此次审计工作被标注为“AI 生成”或辅助完成，展示了利用人工智能技术进行大规模代码审查和模式识别的潜力。开发团队承诺所有原始数据、分类依据及修复策略均已开源，允许外部开发者验证和复现。
事件分析
此次事件深刻揭示了底层系统编程语言迁移的复杂性。从 Zig 转向 Rust 虽然旨在提升内存安全性和开发体验，但这一过程并非简单的翻译，而是需要重新审视内存布局和所有权模型。大量的 `unsafe` 代码表明，当前的移植更多是“形式上的迁移”，尚未充分发挥 Rust 编译器的静态分析优势。这在高性能运行时开发中具有典型代表性：为了追求极致性能或兼容现有 C/C++ 生态，开发者往往不得不绕过安全检查。审计中提到的 5 个 Soundness Bug 进一步证明，仅仅使用 Rust 语言并不能自动保证安全，盲目的 `unsafe` 使用反而可能引入比手动内存管理更隐蔽的漏洞。此外，报告中强调的“AI 生成”属性，暗示了大型语言模型（LLM）在代码重构和静态分析中的应用趋势。AI 能够处理人类难以企及的代码量级，识别出数千个潜在的改进点，这标志着软件开发正从人工编码向人机协作的审计与修复演进。对于 Rust 生态而言，这也是一次极佳的案例研究，展示了如何量化和管理技术债务。
💡 核心观点：高性能运行时的 Rust 迁移不仅是语法转换，更是对系统底层设计的重构；大规模 unsafe 代码的清理离不开 AI 辅助工具的介入。
原文链接：Hacker News
评论前必须登录！
立即登录 注册