goroutine 中 panic 不会传播到主 goroutine，必须在每个 goroutine 内部用 defer+recover 捕获；recover 仅对同 goroutine 的 panic 有效，且必须紧随 defer 使用，不可全局兜底或依赖 context。
goroutine 里 panic 不会传播到主 goroutine
Go 的 goroutine 是独立的执行单元，panic 发生后只会终止当前 goroutine，不会像主线程那样让整个程序崩溃，但也不会被自动捕获或上报——这意味着错误静默丢失是常态。
常见错误现象：panic: runtime error: invalid memory address 只在日志里一闪而过，主逻辑照常运行，你却完全不知道某个异步任务早已失败。
- 必须在每个可能 panic 的 goroutine 内部用
recover()捕获，不能依赖外层 -
recover()只在defer中调用才有效，且仅对同 goroutine 的 panic 生效 - 不要把
recover()放在函数开头或中间，它必须紧挨着defer
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("goroutine panic: %v", r)
}
}()
// 可能 panic 的逻辑，比如 map 并发写、nil 解引用等
m := make(map[string]int)
go func() { m["x"] = 1 }() // 这里会 panic
}()
recover 必须搭配 defer 才生效
recover() 不是 try/catch，它本质是个“panic 后的现场快照函数”，只在 defer 链中且 panic 正在发生时返回非 nil 值；其他任何调用时机都返回 nil。
使用场景：处理第三方库调用、JSON 解析、类型断言、反射操作等易 panic 的异步逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 单独写
recover()而不包在defer里，永远拿不到 panic 值 - defer 函数里如果用了命名返回值或闭包变量，注意它们捕获的是 defer 定义时的值，不是 panic 时刻的上下文
- 别在 defer 里再抛 panic，否则上层 recover 不到（除非再套一层 defer）
别用全局 recover 或中间件式兜底
有人试图在 main 入口加一层 defer recover() 来“统一捕获所有 goroutine panic”，这完全无效——因为 panic 不跨 goroutine 传播。
性能 / 兼容性影响：这种写法不仅没用，还会制造虚假安全感。Go 1.21+ 的 debug.SetPanicOnFault(true) 也只影响当前 goroutine，不改变这一行为。
- 不存在“全局 panic 捕获钩子”，Go runtime 明确禁止跨 goroutine 错误传递
- 想集中处理？只能靠封装：写一个带
defer/recover的启动函数，所有异步任务都通过它起 - 例如：
go WithRecover(func() { ... })，其中WithRecover内部做了标准 recover 流程
context.Context 无法捕获 panic，但能配合做超时和取消
context.Context 是用来控制生命周期和传递取消信号的，和 panic 无关。有人误以为 ctx.Done() 能感知 panic，其实不能。
容易踩的坑：在 goroutine 里监听 ctx.Done() 并退出，但忘了 recover，结果 panic 仍会丢弃；或者反过来，recover 了却没检查 ctx 是否已取消，导致继续执行无意义逻辑。
- recover 和 context 应该并存：先 defer recover，再在业务逻辑里定期
selectctx.Done() - panic 后 recover 到的错误，可以用
log.Error或发送到 channel，但别试图用 context.Value 传 panic 值——context 不设计用于错误传递 - 测试时记得覆盖 panic 场景：用
testing.T.Parallel()+ 显式触发 panic，验证 recover 是否真起作用
<nil> 或地址，要用 fmt.Sprintf("%+v", r) 或 errors.As(r, &e) 做类型断言才能拿到真实错误信息。 
