Rust — panicked：对 None 调用 Option::unwrap()

症状

　　panic 信息是一份地址而不只是一个错误：thread ‘main’ panicked at ‘called Option::unwrap() on a None value’, src/parser.rs:117:32——117 行 32 列就是那个 unwrap。用生产输入复现并开 RUST_BACKTRACE=1，回溯会显示是谁产出了这个 None，那才是真正的 bug 语境。输入依赖性是最强提示：单测用良构数据全过，panic 在第一次遇到可选字段缺席时出现——这是正常条件，只是代码当它不可能发生。

诊断思路

　　先拿精确位置与回溯；再用产生 None 的生产输入写成测试（–nocapture 跑），把崩溃变成永久回归用例；最后盘点 unwrap 清单——每个能被外部输入触达的 unwrap 都是在等它的输入的 panic，这份清单就是加固面。原型期写下的 unwrap 混进发布代码、嵌套长表达式里的 unwrap 链让人分不清哪个失败，都是常见成因。

根因

　　unwrap 断言 Option 必是 Some（或 Result 必是 Ok），否则 panic。这个 panic 不是内存损坏——它是“对一个可以合法缺席的值缺失了决策”。失败输入在生产中触达了被 unwrap 的表达式，而程序员当时假设它必然存在。

修复与验证

　　按“缺席意味着什么”来选：预期中的缺席做显式处理（map 加 unwrap_or_else 配文档化默认值）；失败用自定义错误类型加 ? 传播；真正的恒常条件可以 panic，但必须 expect(“具体原因”) 说清为什么；用 clippy lint 或 CI grep 门禁压住非测试代码的 unwrap（评审过的白名单除外）。验证时此前 panic 的生产输入现在产生类型化错误或优雅降级；unwrap 审计显示零个“输入可达”的 unwrap。警惕把 unwrap 全换成 unwrap_or_default——那会静默捏造数据，缺席要么有意义地处理、要么传播错误。

代码示例

thread 'main' panicked at 'called `Option::unwrap()` on a `None`
value', src/parser.rs:117:32

RUST_BACKTRACE=1 cargo run -- bad-input.csv

let locale = headers.get("x-locale")
    .map(|v| v.to_owned())
    .unwrap_or_else(|| "en-US".to_string()); // documented default

fn parse_count(raw: &str) -> Result<u32, ParseError> {
    raw.parse::<u32>().map_err(|e| ParseError::Count {
        raw: raw.into(), source: e,
    })
}
// callers: ? propagates, no panic anywhere

let conn = pool.get().expect("pool guarantees a live connection");