no_std环境下Rust非显式调用panic/unwrap的panic场景及校验方法

除了你已经列出的5类场景，core环境下还存在以下常见隐式/显式panic触发点：

• 内置宏触发：除了显式panic!，unimplemented!()、unreachable!()、assert!()三个宏在所有构建模式下都会触发panic，debug_assert!()系列宏仅在debug构建下触发panic，这类触发点经常散落在逻辑分支和依赖代码中，很容易被漏过。
• Core库隐式校验panic：Option::expect()、Result::expect()和unwrap()行为一致，传入错误状态时会直接panic；除此之外core库内部大量安全方法会做隐式校验，校验失败直接panic，常见的包括：
  • 所有切片、str类型的索引操作越界（数组越界你已经覆盖，注意普通&[T]切片、字符串切片的索引逻辑完全一致，越界即panic）
  • 切片相关方法的参数校验失败：比如copy_from_slice()传入的源切片和目标切片长度不匹配、split_at()/split_at_mut()传入的分割位置超出切片长度、swap()传入的索引越界等
  • 有符号整数除法/取余的特殊溢出场景：当有符号整数作为被除数取类型最小值（比如i32::MIN）、除数为-1时，无论debug还是release构建都会触发panic，这一场景不受release模式下整数溢出wrapping规则影响
  • 整数取余（%）操作除数为0时，和除零错误一致，所有构建模式下都会panic
• RefCell<T>运行时借用检查失败：RefCell是core库提供的内部可变性容器，运行时会严格执行Rust借用规则，如果违反“同一时刻只能有一个可变引用、或任意多个不可变引用”的规则，调用borrow()/borrow_mut()时会直接panic。
• 非法枚举判别式访问：如果通过unsafe代码构造了枚举类型的非法判别式值（比如给一个只有2个变体的枚举，写入判别式值5），对该枚举值做模式匹配时会触发panic。
• 非法字符串构造：通过安全方法构造&str类型时，如果传入的字节序列不符合UTF-8编码规范，会触发panic（注意unsafe的from_utf8_unchecked不做校验，不触发panic但会产生UB）。

答案是不存在通用方法可以对任意Rust代码做到100%无panic路径的静态确认，核心原因是判定任意程序是否存在某条可触发panic的执行路径，等价于图灵机停机问题，理论上就不存在通用的全判定算法。
目前社区常用的方案只能尽可能降低panic漏过的概率，做不到绝对100%覆盖：

• Lint检查：开启clippy的全量规则，重点开启clippy::unwrap_used、clippy::expect_used、clippy::integer_arithmetic、clippy::unwrap_in_result等规则，可以把显式的unwrap、expect、未做显式处理的整数运算、显式panic宏全部拦在编译期，但无法识别隐式的panic触发点（比如索引越界、切片长度不匹配、RefCell借用冲突等）。
• 符号执行与形式化验证：用符号执行工具对代码做全路径验证，可以在给定前置约束（比如输入值范围、硬件寄存器行为模型）的前提下，验证覆盖范围内的代码不存在panic路径。这类工具的验证精度很高，但需要人工编写验证前置条件、对unsafe代码做额外的正确性证明，且对代码规模有一定限制，无法无约束地对大型项目做全量验证。
• 编译产物检查：通过检查编译生成的二进制文件中是否链接了panic处理函数，判断代码是否包含panic路径，这类方案容易受编译器优化、泛型实例化、依赖代码隐式引入panic路径的影响，存在较高的误报和漏报率，只能做辅助检查。
• 实践层面的工程方案：嵌入式no_std场景下，通常会结合lint检查、全量模糊测试、符号执行覆盖核心逻辑、整数运算全程使用checked_*/saturating_*/wrapping_*显式指定溢出行为、避免在核心路径使用RefCell这类带运行时检查的容器、所有切片操作前加长度校验的方式，把panic风险降到最低。你之前开发的嵌入式驱动模糊测试框架属于动态测试方案，和静态检查、符号执行形成互补，但同样受限于输入生成的覆盖度，无法保证遍历所有可能的执行路径，不存在数学意义上的100%无panic保证。

内容的提问来源于stack exchange，提问作者silvergasp