11.1 unsafe 块的使用场景

Rust 的设计哲学是在保证内存安全的前提下提供零成本抽象。然而，在某些底层编程场景中，编译器无法验证操作的安全性，或者需要执行语言本身禁止但实际安全的操作。此时，Rust 允许通过 unsafe 块显式绕过部分安全检查。需要注意的是，unsafe 并不意味着“危险”或“错误”，而是表示“此处的安全性由程序员负责，而非编译器”。

根据 Rust 语言规范，unsafe 块内允许进行以下五类操作：

1. 解引用原始指针

Rust 中的原始指针（*const T 和 *mut T）不具有所有权语义，也不受借用检查器约束。解引用它们必须在 unsafe 块中进行：

let x = 5;
let raw = &x as *const i32;
unsafe {
    println!("{}", *raw); // 解引用原始指针
}

程序员必须确保指针非空、对齐正确、指向有效内存，且无数据竞争。

2. 调用不安全函数

某些函数因其内部行为无法被编译器完全验证，被标记为 unsafe fn。调用它们需要 unsafe 块：

unsafe fn dangerous_function() {
    // 可能包含未定义行为
}

unsafe {
    dangerous_function();
}

标准库中的许多底层函数（如 slice::from_raw_parts）属于此类。

3. 访问或修改可变静态变量

全局可变状态在多线程环境下极易引发数据竞争，因此访问 static mut 变量是不安全的：

static mut COUNTER: u32 = 0;

unsafe {
    COUNTER += 1;
    println!("{}", COUNTER);
}

现代 Rust 更推荐使用 std::sync::atomic 或 lazy_static! 等安全替代方案。

4. 实现不安全 trait

某些 trait（如 Send、Sync）的实现可能影响内存安全，因此其实现必须标记为 unsafe：

struct MyType;

unsafe impl Send for MyType {}
unsafe impl Sync for MyType {}

只有当开发者能证明该类型在线程间转移或共享是安全的，才应手动实现。

5. 访问 union 字段（较少见）

Rust 中的 union 允许字段重叠存储，读取非活跃字段是未定义行为，因此访问 union 字段需在 unsafe 块中。

安全封装原则

使用 unsafe 的最佳实践是：将不安全操作封装在安全的 API 内部。例如，标准库的 Vec<T> 内部大量使用 unsafe，但对外提供完全安全的接口。开发者应遵循这一模式——尽可能缩小 unsafe 块的范围，并通过文档和测试确保其前提条件始终满足。

小结

unsafe 是 Rust 与底层系统交互的桥梁，但它不是逃避安全规则的借口。合理使用 unsafe 意味着在明确理解其风险的前提下，构建出既高效又可靠的抽象。在后续章节中，我们将看到它在 FFI、内存布局控制等场景中的具体应用。