recover只对同goroutine有效，主goroutine的defer无法捕获子goroutine的panic；必须在每个子goroutine内单独使用defer/recover或工具如conc/panics.Try进行就地拦截与上报。
为什么主 goroutine 的 defer 捕不到子 goroutine panic
因为 recover() 只对当前 goroutine 有效——这是 Go 运行时的硬性限制，不是 bug，也不是配置问题。你写在 main() 里的 defer func() { recover() }，永远捕获不到 go func() { panic("boom") }() 里触发的 panic。
- 现象：服务突然退出，日志里只看到
panic: boom和一串 goroutine 18 的堆栈，但main函数里加的 recover 完全没生效 - 根本原因：panic 发生在新 goroutine 中，而 recover 必须和 panic 在同一个 goroutine 内、且在 panic 向上传播前调用
- 错误做法：只在 main 入口加一层 defer —— 这只能保 main 自己，对所有
go启动的逻辑完全无效 - 正确姿势：每个
go启动的函数入口，都得自己包一层defer/recover，或者用封装好的工具（比如conc/panics.Try）
怎么让 goroutine panic 不炸掉整个服务
目标不是消灭 panic，而是不让它传播到 goroutine 边界外。最稳妥的方式是“就地拦截 + 上报”，而不是指望全局兜底。
- 手动封装：在每个 worker 函数开头加
defer func() { if r := recover(); r != nil { log.Printf("goroutine panic: %v\n%v", r, debug.Stack()) } }() - 用现成库更省心：
conc/panics.Try能直接返回 panic 值和堆栈，不用手写 recover 模板：recovered := panics.Try(func() { riskyMapWrite() })<br>if recovered != nil { /* 处理 */ } - 注意别踩坑：recover 后不要做网络请求、数据库写入等可能再 panic 的操作；也别试图“恢复执行”，recover 后函数已终止，只能做清理和记录
- 如果用了
errgroup.Group或sync.WaitGroup，记得每个 goroutine 都要独立 recover —— 共享一个 error channel 不等于共享 recover 能力
如何快速定位是哪个 goroutine、哪行代码崩的
光靠终端里一闪而过的 panic 输出，90% 的时候找不到源头。必须让堆栈信息“可读、可比、可追溯”。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先设环境变量：
GOTRACEBACK=all，否则默认只打当前 goroutine，而并发崩溃往往发生在别的 goroutine 里 - 立刻上
panicparse：把崩溃输出管道过去，your-service 2>&1 | pp，它会把几十个 goroutine 的堆栈按状态分组、标出阻塞点、高亮 panic 源头 - 配合
pprof看 goroutine 分布：curl 'http://localhost:6060/debug/pprof/goroutine?debug=2'，重点扫那些停在chan send、sync.(*Mutex).Lock或runtime.gopark的，它们常是 panic 前卡住的“遗体” - 别信本地复现：高并发下 panic 往往和竞态有关，一定要用
go run -race跑一遍，很多“偶发崩溃”其实是fatal error: concurrent map writes被掩盖了
为什么加了 recover 还是看不到 panic 日志
常见假象：写了 recover，但日志没打出来，服务照样静默退出。大概率不是 recover 失效，而是日志被吞了或写到了不可见地方。
立即学习“go语言免费学习笔记（深入）”；
- 检查日志是否输出到
stderr：很多 recover 日志用fmt.Println打，但生产环境常重定向stdout，而stderr没配日志采集 - 确认 panic 是否真被 recover：在 recover 里加一行
log.Printf("PANIC CAUGHT: %v", r)，并确保 log 输出路径可写、无权限问题 - 警惕 context cancel 干扰：如果 goroutine 是用
ctx.Done()控制生命周期的，select分支里忘了处理case ，可能导致 panic 发生前 goroutine 已被取消，recover 来不及运行 - 终极验证法：在 recover 里故意写个
panic("test")，看会不会打出第二段 panic —— 如果打了，说明原 panic 确实被捕获了；如果没打，说明压根没走到那行
实际调试中最容易卡住的，是以为“加了 recover 就万事大吉”，结果 panic 被 recover 了，但日志路径错了、格式乱了、或者被更高层的 defer 覆盖了——堆栈还在，只是你没看见。
