编译通过以后，我还不能说这段 Rust 安全

对刚转Rust的我来说，编译器是很可靠的老师，但老师不会替我理解全部题意。一段代码可以完全不用unsafe，仍然把负偶数漏掉；另一段代码通过编译，也可能把不满足约定的指针传进C库。两种错误不能混成一句“Rust也不安全”。

编译器管的不是所有正确性

安全Rust的类型与借用规则约束内存访问，不能证明业务条件写对、任务一定结束或远端只执行一次。下面两个函数都能编译，第二个却把“第一个偶数”擅自改成了“第一个正偶数”。

fn first_even(xs: &[i32]) -> Option<i32> { xs.iter().copied().find(|x| x % 2 == 0) } fn wrong(xs: &[i32]) -> Option<i32> { 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生成代码时，至少不会因为绿色编译输出，就跳过题意和跨语言契约。