recover对fatal error完全无效，因其仅能捕获runtime.panic()引发的panic；而fatal error（如栈溢出、内存耗尽、非法指针解引用）由runtime.throw()或底层运行时直接终止进程，不走panic流程，recover无执行机会。
recover 为什么对 fatal error 完全无效
recover 只能拦截由 runtime.panic() 触发的 panic，而 fatal error（如 fatal error: stack overflow、fatal error: out of memory、fatal error: invalid pointer dereference）是由 runtime.throw() 或底层运行时直接终止进程，不走 panic 流程。此时 goroutine 栈已被破坏或内存已不可用，recover() 根本没有执行机会。
典型表现是：程序静默退出、控制台只打印一行 fatal error: xxx、无 stack trace、日志里完全找不到痕迹。这不是 recover 没写对，而是它压根不参与这个路径。
-
runtime.throw()是非 recoverable 的硬终止，常见于 map 并发读写、栈溢出、非法指针操作 - 一旦触发
throw，当前 goroutine 立即被 runtime 杀掉，所有 defer（包括含recover()的）都不执行 - 即使你在 main 函数开头就注册了
defer func(){ recover() }()，也拦不住throw
哪些 panic 实际上也无法被 recover 捕获
不是所有以 panic: 开头的错误都能被 recover() 拦住。关键看 panic 是否发生在用户可控的 runtime 层——有些 panic 表面像普通 panic，实则是 runtime 在崩溃前的“最后通牒”。
-
panic: runtime error: invalid memory address or nil pointer dereference：多数情况可 recover，但若解引用的是非法地址（如0x1而非nil），可能直接触发throw - 使用
unsafe手动构造 slice header 并越界写入（如修改b[0]指向非法内存），会绕过 Go 的边界检查，导致 segfault 级崩溃，recover()无效 - 调用
os.Exit()后，整个进程立即终止，defer 不执行，recover()无从谈起 - 子协程中发生 panic，但该 goroutine 内没写
defer+recover，主 goroutine 的 recover 对其完全不可见
如何定位到底是 panic 还是 fatal error
看错误输出的第一行和后续行为是最直接的方式。真正 fatal 的错误不会给你留 stack trace，也不会进 defer 链。
- 可 recover 的 panic：输出以
panic:开头 + 完整 goroutine stack trace +exit status 2（或类似） - 不可 recover 的 fatal：输出以
fatal error:开头 + 单行说明 + 程序立即退出，无 goroutine 列表 - 静默退出（无任何输出）：大概率是
os.Exit()、SIGKILL、或 runtime 已无法维持基本状态（如严重内存损坏） - 加
GODEBUG=asyncpreemptoff=1启动可排除异步抢占干扰，但不能解决 fatal 场景
fatal 场景下唯一可行的日志捕获手段
既然 recover() 失效，就得绕过 Go 运行时，依赖操作系统能力把 stderr 重定向到文件——这是 Windows 和 Linux 下都可用的兜底方案，尤其适合服务类程序。
- 在程序启动早期（main 第一行）就调用
RedirectStderr()，确保 fatal 错误输出至少落到磁盘 - Linux 下用
dup2(int, int)替换stderr文件描述符；Windows 下调用kernel32.dll的SetStdHandle - 注意：重定向后仍需显式设置
os.Stderr = logFile，否则log.Printf等仍打到原 stderr - 该方式捕获的是“输出”，不是“错误对象”，所以无法做类型判断或自动恢复，但至少能看清 crash 原因
fatal 错误的本质是运行时已无法保证程序逻辑的完整性，任何试图“恢复执行”的做法都是危险的。真正要做的，是在开发阶段通过 race detector、go vet、静态分析和压力测试提前暴露这些点，而不是指望线上靠 recover 救命。
