Unsafe 代码升级先验证不变量和所有权边界Unsafe 块能绕过编译器检查也把证明责任交给维护者。依赖或编译器升级前先确认这些证明是否仍成立。把安全前提写在函数边界指针是否对齐、内存是否初始化、别名规则和生命周期由谁保证都应靠类型、断言或 Safety 注释表达。不要只写“调用者负责安全”。升级检查从 UB 风险开始运行现有测试之外再用 Miri、sanitizer 或目标平台工具覆盖边界输入。FFI 代码要核对 ABI、结构体布局和析构责任。缩小 Unsafe 块的作用域。为每个原始指针标明来源与有效期。依赖版本变化时重查上游 Safety 契约。失败路径同样属于证明提前返回、panic 或回调失败时资源必须仍按既定顺序释放。升级后若析构时机改变表面通过的主路径也可能留下悬垂引用。Unsafe 并不可怕含糊的不变量才可怕。把假设写成能被工具和评审检查的边界升级会踏实很多。