rust 中 panic! 不是未处理自定义错误所致，而是 unwrap()/expect() 遇 err 或 result 未解包触发的设计行为；避免崩溃需用 match、? 或 map_err；? 不 panic，仅传播错误，要求函数返回 result 且错误类型可 from 转换；main 可返回 result 实现优雅退出；部分 panic（如 assert、refcell 借用冲突、线程 panic）无法用 ? 拦截，须针对性防御。
直接说结论：Rust 中的 panic! 不是“未处理自定义错误”导致的，而是 Result 未被显式解包、或调用了 unwrap()/expect() 且内部值为 Err 时触发的——这是设计使然，不是 bug，更不是“错误没处理好”的失职。真要避免进程崩溃，就得放弃强制解包，改用 match、? 或 map_err 等可控路径。
为什么 unwrap() 和 ? 在语义上完全不同
unwrap() 是无条件 panic 的快捷方式；? 是传播错误的控制流操作符，只在函数返回 Result 时有效，且会把 Err 向上交由调用方决定——它不崩溃，除非最外层函数没接住。
-
unwrap()等价于match self { Ok(v) => v, Err(e) => panic!("called `Result::unwrap()` on an `Err` value: {:?}", e) } -
?展开后实际是match self { Ok(v) => v, Err(e) => return Err(From::from(e)) }，完全不 panic - 如果函数签名没写
-> Result<t e></t>，?就根本不能用，编译器直接报错
自定义错误类型必须实现 From 才能让 ? 自动转换
否则 ? 会编译失败，很多人卡在这一步就退回用 unwrap()，结果又崩了。关键不是“定义了错误”，而是“能否被自动转成当前函数声明的错误类型”。
- 假设你的函数返回
Result，而你调用了可能返回io::Error的File::open() - 必须为
MyError实现From<:error></:error>，否则File::open(...)?编译不过 - 同理，若还用了
ParseIntError，也得实现From<parseinterror></parseinterror> - 别手动写每个
From实现，用thiserrorcrate 的#[derive(Error)]自动生成（它默认派生所有字段类型的From）
main 函数里怎么接住最后的 Err 而不 panic
Rust 的 main 函数允许返回 Result，这是唯一能避免顶层 panic 的合法方式。很多教程没提这点，导致大家硬塞 unwrap() 进 main。
- 把
fn main()改成fn main() -> Result> - 所有可能出错的操作后面都跟
?，错误会一路冒泡到main返回值 - 程序退出码自动设为 1，标准错误输出打印错误信息（含
source()链） - 不需要额外
match或println!，Rust 标准库已内置处理逻辑
哪些情况真的没法避免 panic
不是所有 panic 都能靠改错误处理消灭。有些是逻辑断言失败（assert!）、线程恐慌（std::thread::spawn 中未捕获的 panic）、或全局状态冲突（如 RefCell::borrow() 重入），这些和自定义错误无关，得靠防御性编程提前拦截。
-
RefCell和Rc的运行时借用检查失败会 panic，不能用?拦截，只能用try_borrow()手动判断 - 多线程中子线程 panic 默认终止整个进程，要用
std::panic::catch_unwind包裹，但仅限于UnwindSafe类型 -
assert!/debug_assert!是开发期校验，发布版可被禁用，但不应依赖它做错误恢复
真正难的不是写出不 panic 的代码，而是分清哪些 panic 是可预防的流程分支，哪些是必须终止的逻辑矛盾——后者不该被“修复”，而该被重构掉。
