直接回答：unwind（默认）在 panic 时逐层展开栈、执行 Drop，可被 catch_unwind 捕获，线程级隔离；abort 直接终止进程，没有展开也没有清理。取舍：服务端选 unwind，配合框架把请求级 panic 隔离成 500；嵌入式、对二进制体积与启动速度敏感、或认为 panic 即不可恢复逻辑错误的场景选 abort，可省掉展开表，体积与性能略优。FFI 边界上 panic 跨语言展开是 UB，必须用 catch_unwind 或 panic=abort 拦住。
展开解析：细节一：catch_unwind 要求 UnwindSafe，因为展开后共享数据的内部一致性可能被破坏（比如 mutex 保护的临界区改了一半 panic），标准库的 Mutex 用中毒（poisoning）机制标记这种不确定性，锁中毒后 unwrap 会再 panic，逼迫调用方显式决策。细节二：panic 策略是编译期全图一致的——依赖树中任何一处以 abort 编译，整个二进制就是 abort，库作者不应假设策略。细节三：abort 下析构函数不跑，临时文件、锁、外部资源可能残留，适合“快速失败 + 外部编排重启”的部署形态（K8s 拉起新 Pod）。细节四：FFI 惯例是 C 边界用 catch_unwind 捕获并转成错误码，同时把 AssertUnwindSafe 用在确认无副作用的闭包上。观测上无论哪种策略都建议装 panic hook 打日志与堆栈，生产环境的静默 panic 是排查噩梦。
追问方向：Mutex 中毒应该如何处理？panic hook 里能做什么不能做什么？
（约 490 字）