debug.stack 不是 panic 分析工具，仅返回当前 goroutine 调用栈快照；真要分析 panic，须在 defer+recover 中先 recover() 再紧接调用 debug.stack() 获取含触发点的栈，返回 []byte 需转 string；debug.printstack 无法捕获输出，仅适用于本地调试。
debug.Stack 不是 panic 分析工具，它只返回当前 goroutine 的调用栈快照，不包含 panic 信息、错误类型或恢复点。真要分析 panic，得靠 recover + debug.PrintStack 或更稳妥的 runtime/debug.Stack 配合错误捕获逻辑。
panic 发生时怎么拿到完整栈信息
直接调用 debug.Stack() 在 panic 中间件外执行，返回的是调用它的那一行的栈，和 panic 无关。必须在 defer + recover 里用，且要先 recover() 拿到 panic 值，再调用 debug.Stack() —— 否则栈里看不到 panic 触发点。
常见错误现象：panic: runtime error: index out of range 发生后，debug.Stack() 却只显示 main.main 或 runtime.goexit，没看到出错的切片访问行。
- 必须在
defer func() { if r := recover(); r != nil { ... } }()里调用 - 调用
debug.Stack()前不能有其他函数调用（避免栈帧污染），建议紧接在recover()后 - 返回值是
[]byte，记得用string(...)转成可读字符串
为什么 debug.PrintStack 不够用
debug.PrintStack() 会直接输出到 os.Stderr，无法捕获、格式化或写入日志系统。线上服务通常需要把 panic 栈存进结构化日志（比如带 traceID、level=“error”），这时候硬打屏就失控了。
使用场景：本地调试快速看栈可以，CI 测试或生产环境必须用 debug.Stack() 获取原始字节流，再交给日志库处理。
-
debug.PrintStack()是 “fire-and-forget”，没法做条件判断或上下文注入 - 它内部调用的正是
debug.Stack()，只是多了一步fmt.Fprintln(os.Stderr, ...) - 若已重定向
os.Stderr（如测试中用os.Pipe()），PrintStack输出可能被吞掉，而Stack()返回值始终可控
如何安全获取 panic 时的 goroutine 栈（含 goroutine ID）
debug.Stack() 只返回当前 goroutine 的栈，但 panic 可能发生在任意 goroutine。如果主 goroutine 已退出，仅靠它无法定位问题源头。需要结合 runtime.Stack 并传 true 参数抓所有 goroutine 栈——但这开销大，仅限诊断阶段启用。
性能影响：全栈 dump 可能达 MB 级，阻塞调度器几十毫秒，绝不能在高频路径或 defer 中无条件调用。
- 线上建议只在
recover()后用debug.Stack()（单 goroutine） - 怀疑是 goroutine 泄漏或死锁时，改用
runtime.Stack(buf, true)手动触发（注意 buf 要足够大，比如make([]byte, 1024*1024)） - Go 1.16+ 可用
runtime/debug.ReadBuildInfo()辅助判断 panic 是否发生在 init 阶段
真正难的不是调用 debug.Stack()，而是确保它出现在 panic 发生后的第一个可观测位置——中间差一层匿名函数、一次日志封装、甚至一个 fmt.Sprintf，都可能让栈顶丢失关键帧。别依赖工具自动补全，手动控制调用时机才是关键。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
