unsafe Rust 放开了哪些能力，工程中应该如何划定 unsafe 边界？

结论：unsafe 只放开五种能力：解引用裸指针、调用 unsafe 函数、访问或修改可变静态变量、实现 unsafe trait、访问 union 字段。工程原则：把 unsafe 收敛到最小边界内，对外暴露安全 API；安全抽象的正确性不能依赖调用方"自觉"。

展开：良好实践是将 unsafe 操作封装在安全函数内部：前置条件用参数校验或类型系统表达，内部用 unsafe 完成编译器无法证明（但人能证明）的部分——std 的 Vec、Mutex 都如此。注意安全代码也可能破坏 unsafe 的前提（例如安全代码修改了 Vec 的 len 字段），所以封装边界要覆盖所有相关不变量。易错点：unsafe 不关闭借用检查器；unsafe impl Send/Sync 的担保责任在实现者；能用安全 API（split_at_mut、MaybeUninit）就不用裸指针运算。追问方向：如何审计 unsafe？cargo geiger 统计 unsafe 用量、Miri 跑测试查 UB、为每个 unsafe 块写 SAFETY 注释说明不变量为何成立。

fn first_byte(slice: &[u8]) -> Option<u8> {
    if slice.is_empty() { return None; }
    // SAFETY: 切片非空，as_ptr 有效且至少可读 1 字节，生命周期受切片约束。
    Some(unsafe { *slice.as_ptr() })
}