解读

在国内 Rust 岗位面试中，这道题常被用来快速区分候选人是否真正写过“生产级”代码。
很多候选人能背出“i32 是带符号、u32 是无符号”，但一旦追问“溢出后到底发生什么”，就开始含糊其辞。
面试官真正想听的是：

1. Debug 与 Release 模式下编译器插入的溢出检查有何不同；
2. i32 与 u32 在溢出后分别得到什么位模式；
3. 如何用显式方法（wrapping、checked、saturating、overflowing）接管行为，而不是让程序“悄悄错”或“直接 panic”。
   答不到这三层，基本会被归为“只写过 toy 项目”。

知识点

1. 编译期常量溢出：直接拒绝编译，与类型无关。
2. 运行时溢出
   • Debug 模式：i32 与 u32 统一插入 panic!，行为一致，一旦溢出立即终止线程。
   • Release 模式：
     – u32：按 2³² 模运算 回绕，结果落在 0..=4294967295，属于“逻辑上可预期”的补码截断。
     – i32：同样按 2³² 模运算 截断，但位模式被重新解释成补码，正溢出变负、负溢出变正，肉眼难以一眼看出错误，因此比 u32 更危险。
3. 显式控制方法（std::num::Wrapping、checked_、saturating_、overflowing_*）可在任何模式下统一行为，是国内代码审计的硬性要求（金融、车联网、区块链团队尤其看重）。
4. #[repr(transparent)] 布局保证：Wrapping<T> 与 T 的 ABI 相同，零成本抽象，可在FFI 边界直接替换，不会破坏 C 接口调用约定。

答案

Debug 模式下，i32 与 u32 溢出都会触发 panic!，行为完全一致；
Release 模式下，两者都执行 2³² 模运算回绕，但u32 结果仍在 0..=4294967295 范围内，i32 的位模式被重新解释为补码，正溢出突然变负、负溢出突然变正，肉眼更难定位 bug。
因此，i32 的溢出比 u32 更隐蔽、风险更高；
生产环境应统一使用显式方法（如 i32::saturating_add、u32::wrapping_mul）接管溢出策略，禁止依赖默认回绕行为。

拓展思考

1. 区块链状态机：余额字段用 u64，但链上规则要求“溢出即交易失败”，不能回绕。团队会在 Release 下强制开启 overflow-checks = true，牺牲 3~5% 性能换共识一致性。
2. 嵌入式 PWM 寄存器：硬件计数器天然 16 bit 回绕，用 Wrapping<u16> 直接映射寄存器，既符合硬件行为又通过审计，无需运行时检查。
3. 面试反杀技巧：若面试官追问“如何全局关闭溢出检查”，可答“在 Cargo.toml 里设置 overflow-checks = false，但国内金融、车规项目 必须通过 GB/T 34963、15746 等静态扫描，禁止关闭，因此更推荐局部使用 wrapping_*”，既展示深度又体现合规意识，容易拿到高分。