Golang Goroutine的Panic堆栈跟踪_定位并发崩溃点

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: %vn%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% 的时候找不到源头。必须让堆栈信息“可读、可比、可追溯”。

• 先设环境变量：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 覆盖了——堆栈还在，只是你没看见。