对刚转Rust的我来说编译器是很可靠的老师但老师不会替我理解全部题意。一段代码可以完全不用unsafe仍然把负偶数漏掉另一段代码通过编译也可能把不满足约定的指针传进C库。两种错误不能混成一句“Rust也不安全”。编译器管的不是所有正确性安全Rust的类型与借用规则约束内存访问不能证明业务条件写对、任务一定结束或远端只执行一次。下面两个函数都能编译第二个却把“第一个偶数”擅自改成了“第一个正偶数”。fn first_even(xs: [i32]) - Optioni32 { xs.iter().copied().find(|x| x % 2 0) } fn wrong(xs: [i32]) - Optioni32 { xs.iter().copied().find(|x| x % 2 0 *x 0) } fn main() { assert_eq!(first_even([-2,4]),Some(-2)); assert_ne!(wrong([-2,4]),first_even([-2,4])); assert_eq!(first_even([0,4]),Some(0)); assert_eq!(first_even([]),None); println!(safe Rust can violate a task contract: counterexamples confirmed); }rustc 1.98.0运行确认了负数、零和空输入的反例。这不是内存不安全示范而是需求错误。区分清楚才知道该补测试还是该重审unsafe边界。unsafe 的证明义务不会因为包装消失The Rustonomicon的FFI章节说明跨语言接口及相关安全约定。一个非空指针仍可能悬空、未对齐、长度不足或不允许当前访问。把它包进安全函数以后维护这些条件就成了包装层的责任不能让调用者猜。2026-10-15的Rust 1.99.1公告也提醒我持续核对工具链修复公告涉及的具体平台问题不能直接当成本机复现结果。本机仍用1.98.0执行本篇例子没有在目标平台重现公告中的问题。多工具给多份有限证据Miri官方仓库介绍它对未定义行为的检查能力和支持限制。Miri能检查实际执行到的Rust路径不证明未执行分支正确也不能任意解释真实C依赖。单元测试验证选中的输入ASan等原生插桩能在相应构建中捕捉一部分内存错误数据竞争检测需要相应工具不能把ASan当作通用竞态检测器。本轮只执行了上面的普通Rust测试。本地没有可用nightly Miri环境也未给任何FFI库做插桩所以不会写“已过Miri/ASan”。图中的覆盖范围是概念关系不是覆盖率测量。我现在给“安全”后面补宾语内存安全、协议正确、业务正确还是权限合规。每一项都对应不同证据。这样读AI生成代码时至少不会因为绿色编译输出就跳过题意和跨语言契约。
