子协程 panic 不会自动传播到主 goroutine，必须在每个子 goroutine 内部用 defer recover 捕获；recover 仅在同 goroutine 的 defer 中有效，且需配合资源清理与日志记录。
子协程 panic 不会自动传播到主 goroutine
Go 的 panic 默认只在当前 goroutine 内生效，子协程里 panic 了，主 goroutine 完全感知不到——不会中断、不会报错、也不会触发任何 recover。这是最常被误以为“recover 失效”的根源。
常见错误现象：go func() { panic("boom") }() 执行后程序照常运行，甚至可能静默退出（如果主 goroutine 已结束）；日志里看不到 panic 信息，监控也抓不到。
- 必须显式在每个子 goroutine 内部做
recover，不能靠外层包一层就完事 - 如果子 goroutine 是通过
go f()启动的普通函数，f内部需自行包裹defer recover - 若用
sync.WaitGroup等待子协程，WG 不会等 panic 后的 panic 堆栈，它只等函数返回
recover 必须和 panic 在同一个 goroutine 中才有效
recover 只能在 defer 函数中调用，且仅当该 defer 所在的 goroutine 正处于 panic 过程中时才返回非 nil 值。跨 goroutine 调用 recover 永远返回 nil。
使用场景：封装一个带 recover 的 goroutine 启动器，比如 GoSafe 或类似工具函数。
立即学习“go语言免费学习笔记（深入）”；
-
defer recover()必须写在 panic 可能发生的同一函数内，不能写在调用它的上层函数里 - 不要试图在主 goroutine 的 defer 里 recover 子 goroutine 的 panic —— 这是无效的
- recover 后建议记录日志（含
debug.Stack()），否则 panic 信息会彻底丢失
示例：
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("panic in goroutine: %v\n%v", r, debug.Stack())
}
}()
panic("subroutine failed")
}()
GoSafe 封装要注意 panic 类型和 error 转换
很多项目会封装一个 GoSafe 函数来统一处理子 goroutine panic，但容易忽略 panic 值本身可能是任意类型（string、error、结构体），直接打印或返回可能 panic 或丢信息。
- recover 返回的是
interface{}，需做类型断言才能安全转成error，例如：err, ok := r.(error) - 如果 panic 是字符串（如
panic("msg")），r.(error)会 panic，应先判断类型再处理 - 不建议把所有 panic 都转成
fmt.Errorf("panic: %v", r)，这会掩盖原始 panic 类型和堆栈 - 某些框架（如 gin）的中间件 panic 捕获逻辑依赖 panic 是否为
error类型，一致性很重要
goroutine 泄漏比 panic 更隐蔽，recover 后别忘了清理资源
recover 能止住 panic，但不代表问题结束。如果 panic 发生在持有 channel、锁、数据库连接或文件句柄的代码段中，recover 后这些资源很可能没被释放。
- defer 清理逻辑必须放在 recover 的 defer 之前，否则 recover 后流程继续执行，但 defer 可能已被跳过
- 推荐结构：先 defer close / unlock / rollback，再 defer recover
- 尤其注意 channel send 操作 panic（如向已关闭 channel 发送），recover 后要确认接收方是否还在等待，否则 goroutine 卡死
- 用
runtime.NumGoroutine()定期检查，长期运行服务里 goroutine 数持续上涨，大概率是 recover 了但没正确退出或清理
事情说清了就结束。
