recover只能捕获同一goroutine内由panic触发的运行时错误，需在defer中直接调用且位置精准，无法跨goroutine或拦截CGO崩溃、编译器内联优化后的底层panic。
panic 会中断当前 goroutine，但不会自动传播到调用方
Go 的 panic 不是传统异常，它只终止当前 goroutine 的执行流，且不会像 Java/C++ 那样向上冒泡。如果你在某个函数里 panic，而调用它的函数没加 recover，那这个 panic 就直接炸到 goroutine 顶层，最终程序崩溃——哪怕外层逻辑完全没问题。
常见错误现象：fatal error: all goroutines are asleep - deadlock! 或直接 panic: runtime error: ... 后退出，但你根本没在出问题的地方写 recover。
- 只有在
defer中调用的recover才有效，且必须在 panic 发生的同一 goroutine 内 -
recover()必须紧跟在defer后面，不能包在另一个函数里（比如defer func(){ recover() }()是无效的） - 跨 goroutine 的 panic 无法被外部
recover捕获，比如go func(){ panic("x") }()，主 goroutine 里的recover完全无感
recover 只能捕获本 goroutine 中由 panic 触发的运行时错误
recover 对逻辑错误（比如空指针解引用、除零、数组越界）没用——这些本身就是 panic 的触发源。它也不是用来兜底“业务异常”的，比如用户输入非法、数据库查不到记录，这类该用返回值或自定义错误类型处理。
使用场景很窄：仅当你要拦截并转化某些**已知可控的 panic 场景**，例如解析第三方 JSON 时允许字段缺失、模板渲染中容忍 nil 值、或封装 C 代码时防止 segfault 泄露到 Go 层。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不要用
recover替代if err != nil，否则掩盖真正需要修复的 bug -
recover()返回interface{}，必须显式类型断言才能拿到 panic 值，比如v, ok := recover().(string) - 如果 panic 是由
nil函数调用或 channel 关闭后发送等导致，recover能拿到，但无法区分具体原因，需结合上下文日志判断
defer + recover 的位置决定你能拦住什么
很多人把 recover 放太外层，以为能一劳永逸。实际上，它只对「从 defer 注册点开始，到函数 return 之间发生的 panic」生效。一旦函数已经 return，再 defer 也没用。
典型错误：在 HTTP handler 最外层加 defer recover()，结果中间某处 goroutine panic 了，handler 还在跑，照样崩。
- 想保整个 handler，就得在 handler 函数开头就
defer func(){ if r := recover(); r != nil { /* log & return */ } }() - 如果 handler 里启动了新 goroutine，那些 goroutine 必须各自配自己的
defer/recover - 注意 defer 的执行顺序是 LIFO，多个 defer 嵌套时，recover 要放在最内层 panic 可能发生的位置之后
runtime.GoPanicXXX 系列函数不走常规 panic 流程
Go 标准库内部有些函数（如 runtime.GoPanicIndex、runtime.GoPanicNil）是编译器直接插入的底层 panic，它们绕过普通 panic 的栈检查和 defer 链，recover 拦不住。
这意味着：数组越界、nil 指针解引用、向 closed channel 发送……这些你写的代码看似没调 panic，但运行时触发的是这类底层 panic，recover 依然能捕获——但前提是它们发生在当前 goroutine 且未被编译器优化掉栈帧。
- Go 1.21+ 对某些 panic 做了更激进的内联优化，可能导致 recover 失效（尤其在测试中开启 -gcflags="-l" 时）
- CGO 调用中发生的 segfault 或 abort，默认不触发 Go 的 panic 机制，
recover完全无效 - 用
go build -gcflags="-S"查看汇编，能确认哪些操作被转成了runtime.GoPanicXXX调用
事情说清了就结束。recover 的边界不是语法层面的“能不能写”，而是运行时控制流的实际可达性——它只在 panic 刚发生、栈还没 unwind 完、且你在同一 goroutine 正确埋点的前提下才起作用。其他地方，老老实实返回 error。
