Unsafe 代码评审：把每条安全前提写在调用边界

Rust 的unsafe不会自动制造错误，它只是把部分证明责任交给程序员。评审的重点不是统计块数量，而是确认每个操作依赖的前提是否真实、持久且可测试。

逐条列出不变量

裸指针是否非空并正确对齐，引用生命周期内内存是否有效，别名规则是否被遵守，类型转换后的布局是否兼容。不要用一句“调用方保证”带过；把要求写进安全 API 的参数类型、构造函数或校验逻辑。

缩小 unsafe 的表面积

将底层操作封装成小函数，安全接口只暴露已经验证的状态。错误路径和析构同样要检查，部分初始化的对象不能被当作完整值释放。涉及 FFI 时还要确认调用约定、所有权与 panic 边界。

门禁辅助而非代替判断

格式、lint、测试和 Miri 可拦截一部分问题，无法证明外部 C 库或设备内存满足约定。评审记录应保留不变量、证据与反例测试，让后续修改知道哪些条件不能破坏。

unsafe的价值是建立受控出口。出口越小、前提越具体，系统越容易维护。