Rust unsafe 代码安全封装工程化：从未定义行为到内存安全的系统性防线

在 Rust 工程师的日常工作中，unsafe 是一个微妙的存在。它既是突破编译器约束的利器，也是潜在未定义行为（UB）的温床。标准库中约有 1.2 万个 unsafe 用法点，tokio 中超过 800 处，sdk 系列库几乎无处不在。然而，unsafe 本身不是风险，风险在于如何封装 unsafe。本文将从 Rust 内存模型的底层规则出发，通过三个递进的工程案例，展示如何将 unsafe 代码系统地封装为可验证、可测试、可维护的安全抽象。

一、理解 unsafe 的边界契约

很多工程师对 unsafe 的误解在于认为它"关闭了借用检查器"。实际上，unsafe 块仍然受借用检查保护，但它授予程序员四项额外能力：解引用裸指针、调用 unsafe 函数、访问可变静态变量、实现 unsafe trait。理解 unsafe fn 与 unsafe 块的语义差异是封装的第一步。

unsafe fn 是对调用者的契约声明："调用此函数时，你必须手动保证前置条件成立"。而 unsafe 块是程序员向编译器做出的承诺："我在此处保证了所有安全不变量都被满足"。这一区别直接决定了封装策略：

// 对外暴露的 safe API：前置条件由函数签名强制保证
pub fn get_unchecked