Go panic堆栈是定位问题的唯一可信线索，需关注goroutine ID、函数签名、文件名:行号三部分；debug.Stack()比默认堆栈更可靠，可捕获全量goroutine状态及created by信息。
Go 的 panic 堆栈不是“看看就行”的辅助信息，它是定位问题的唯一可信线索。不解析堆栈，等于在日志里瞎找。
panic 堆栈里每一行代表什么
默认 panic 输出类似这样：
panic: runtime error: invalid memory address or nil pointer dereference goroutine 1 [running]: main.(*User).Greet(...) /path/to/main.go:10 main.main() /path/to/main.go:15
关键看三部分：goroutine ID、函数签名、文件名:行号。其中 ... 表示该调用未展开完整参数（Go 默认省略），但行号绝对可靠；goroutine 1 [running] 说明这是主 goroutine，且当前处于运行态——没卡在 channel 或锁上。
- 第一行 panic 消息告诉你错误类型，比如
invalid memory address or nil pointer dereference就是典型的 nil 指针解引用 - 第二行起是调用栈：最上面是 panic 发生点，越往下越早被调用
- 行尾的
+0x5是汇编偏移量，调试时有用，日常排查可忽略
为什么 debug.Stack() 比默认堆栈更可靠
默认 panic 堆栈只打印当前 goroutine 的活跃帧，而 debug.Stack() 返回完整 goroutine 列表快照，包含所有正在运行、阻塞、休眠的 goroutine 状态。这对排查死锁、goroutine 泄漏至关重要。
立即学习“go语言免费学习笔记（深入）”；
-
debug.Stack()返回[]byte，需转成string才能写入日志 - 它会包含
created by信息，明确告诉你某个 goroutine 是谁 spawn 的 - 在 recover 中调用时，务必确保 defer 函数没被内联（加
//go:noinline注释可强制）；否则可能丢失上层调用帧
常见堆栈误读与修复方式
堆栈看起来清晰，但容易掉坑：
- 看到
runtime.gopark不代表代码有 bug，它只是 Go 调度器让 goroutine 睡眠的正常行为；重点看它上面一层是谁调的 - HTTP handler 崩溃时，堆栈常止于
http.HandlerFunc.ServeHTTP，真正问题在你自己的 handler 函数里——要顺着created by往回找注册点 - 使用第三方中间件（如 Gin 的
recovery）时，堆栈可能被截断；建议在中间件里手动补全debug.Stack()，而不是依赖它默认的日志 - CGO 调用崩溃时，堆栈会混入 C 函数符号，
debug.Stack()无法捕获 C 层调用链；此时需用runtime.Caller配合runtime.FuncForPC手动拼接
生产环境堆栈必须带 trace 上下文
单看堆栈只能知道“哪里崩了”，不知道“谁触发的”。线上服务必须把 trace ID、请求路径、用户 ID 等注入 panic 日志。
- 不要在 recover 里只打
log.Printf("panic: %v", r)，至少补上req.URL.Path和req.Header.Get("X-Request-ID") - 用
zap.String("trace_id", traceID)这类结构化字段，别拼字符串；否则日志系统没法做聚合分析 - goroutine ID（
goid）比时间戳更有价值——同一秒内多个 panic 可能来自不同 goroutine，靠时间对不上
堆栈本身不会说谎，但少一个字段，排查时间就翻倍。尤其在微服务调用链里，没有 trace ID 的 panic 日志，基本等于废日志。
