直接回答：Miri 是 Rust MIR 的解释器——不走编译产物，逐条解释执行中间表示，因此能在运行时跟踪每块内存的借用栈、初始化状态、对齐信息，抓出编译期与常规测试抓不到的 UB：越界访问、use-after-free、未初始化读、违反 Stacked Borrows 的别名违规、数据竞争（部分）、无效值（如 bool 为 2）。

展开解析：用法：cargo +nightly miri test 直接跑测试套件，解释执行慢一到两个数量级，所以适合小而狠的 unsafe 密集模块配高覆盖测试，不适合全项目全量。能检测的清单值得记牢：解引用悬垂指针、越界、对齐错误、未初始化内存读取（逐字节跟踪）、借用栈违规、调用 ABI 不匹配、无效枚举判别值。边界同样重要：检测是“路径敏感”的——没执行到的路径不报错，所以测试覆盖决定 Miri 效力；不支持所有外部交互——FFI 调 C、内联汇编、系统调用多数不支持（部分可 shim）；并发检测有限——能抓部分数据竞争但弱内存序语义不全；性能语义不检查——UB 之外的逻辑错误管不着。工程实践：unsafe 模块写属性测试（proptest 生成随机操作序列对照 std 行为）再过 Miri，是当前性价比最高的组合；CI 里单独挂 Miri job 而非默认跑，控制时长。记住结论：Miri 全绿不证明无 UB（覆盖不全），但 Miri 报红一定是真问题。

追问方向：proptest 如何与 Miri 配合？sanitizer 与 Miri 的检测面有何互补？

（约 460 字）