崩溃时需在 defer+recover 中调用 runtime/debug.PrintStack 才能输出完整堆栈，避免仅显示末层 panic；PrintStack 输出到 stderr，生产环境推荐用 debug.Stack() 获取字节流以便日志记录或监控上报。
崩溃时自动打印完整堆栈（runtime/debug.PrintStack）
Go 程序 panic 后默认只输出最后一层调用，根本不够定位问题。想看到完整调用链，得在 recover 里主动调用 runtime/debug.PrintStack，而不是依赖 panic 默认行为。
常见错误是只写 log.Fatal(err) 或直接 panic()，结果日志里只有“index out of range”，没上下文。必须把 PrintStack 放进 defer + recover 流程里：
defer func() {
if r := recover(); r != nil {
log.Printf("panic recovered: %v", r)
debug.PrintStack() // ← 这行不能少
}
}()
-
PrintStack输出到os.Stderr，若服务重定向了 stderr（比如 systemd），可能看不到——建议搭配debug.Stack()转成字符串后用 log 输出 - 它不包含 goroutine ID 和状态，纯调用栈；如果要区分协程，得用
runtime.Stack(buf, true) - 频繁调用有性能开销，仅用于异常路径，别放在热循环里
获取当前 goroutine 的原始堆栈字节（runtime/debug.Stack）
和 PrintStack 不同，debug.Stack() 返回 []byte，能存日志、发监控、甚至写入临时文件，更适合生产环境做现场保存。
典型使用场景：程序启动时注册信号 handler（如 SIGUSR1），收到信号就 dump 当前栈，用于非崩溃态的现场快照：
立即学习“go语言免费学习笔记（深入）”；
signal.Notify(sigCh, syscall.SIGUSR1)
go func() {
<-sigCh
buf := debug.Stack()
ioutil.WriteFile("/tmp/stack-$(date +%s).log", buf, 0644)
}()
- 参数为
false时只抓当前 goroutine；设为true才类似pprof/goroutine?debug=2，但会卡住所有 goroutine 等待扫描——线上慎用 - 返回的字节数受
runtime.Stack内部缓冲区限制（默认 4KB），超长栈会被截断，无法保证完整 - 它不包含寄存器值或局部变量，纯调用帧信息；别指望靠它还原 panic 前的变量值
崩溃前保存内存快照（runtime/debug.WriteHeapDump）
WriteHeapDump 是 Go 1.19+ 加入的冷门但关键的能力：程序 panic 前把堆内存写成二进制 dump 文件，配合 go tool trace 或 Delve 可回溯对象分配路径。
注意它不是实时 profile，而是“冻结那一刻”的堆镜像，适合排查 OOM 或诡异对象泄漏：
defer func() {
if r := recover(); r != nil {
debug.WriteHeapDump("/tmp/heap-dump.hprof")
panic(r) // ← 写完再 panic，否则进程退出太快可能写失败
}
}()
- 文件格式是 Go 自有二进制，只能用
go tool pprof或dlv dump解析，通用性差 - 写 dump 本身会暂停所有 goroutine，耗时取决于堆大小；1GB 堆可能卡几百毫秒，别在延迟敏感服务里无条件启用
- 需提前确保目标路径可写且磁盘够大，否则
WriteHeapDump失败但不会报错，静默丢弃
为什么 runtime.Caller 和 debug.Stack 结果不一致
runtime.Caller 返回单层调用位置（文件+行号），而 debug.Stack 是全栈。但很多人发现：用 Caller(1) 拿到的位置，和 Stack() 里第一行对不上——这是因为 panic 触发点和 defer 执行点之间存在 runtime 插入的帧。
例如：panic("x") 发生在 foo() 第 5 行，但 defer 在 foo() 第 2 行注册，runtime.Caller(1) 指向 defer 语句本身，而 debug.Stack() 第一行是 panic 调用点。
- 别用
Caller替代Stack做错误溯源，精度差一层 -
debug.Stack()的第一行是 panic 起始位置，但未必是 bug 根因——可能是上游传入了非法参数，得顺着往上翻几层 - 交叉验证时，优先信
Stack()的完整路径，Caller只适合打点埋码类轻量记录
runtime.Stack(buf, true) 配合 pprof）补全。单靠 debug 包的几个函数，只能解决“在哪崩”，不能回答“为什么崩”。 
