本文介绍如何在 go 中精确捕获 panic 时的堆栈信息（而非依赖 stderr 重定向），利用 `runtime.stack` 获取结构化、可编程处理的 panic 堆栈快照，并结合 `recover` 实现优雅错误捕获与日志增强。
Go 默认在 panic 发生时将完整的 goroutine 堆栈信息输出到 stderr 并终止程序，但这种行为难以定制——例如无法区分 panic 日志与其他错误日志，也无法在退出前做上报、采样或格式化。幸运的是，Go 提供了底层机制，让我们能主动捕获 panic 的原始堆栈数据，而非被动监听标准错误流。
核心方案是组合使用 recover() 和 runtime.Stack()：
- recover() 捕获 panic 的原始值（如 panic("boom") 中的 "boom"）；
- runtime.Stack(buf []byte, all bool) 将当前或所有 goroutine 的堆栈写入字节切片，返回实际写入长度；
- 通过传入 true 作为第二个参数，可获取全部 goroutine 的堆栈快照（类似默认 panic 输出）；传入 false 则仅获取当前 goroutine。
以下是一个完整示例，演示如何在 defer 中安全捕获 panic 并提取结构化堆栈：
package main
import (
"fmt"
"runtime"
"strings"
)
func main() {
defer func() {
if r := recover(); r != nil {
// 获取 panic 值
errMsg := fmt.Sprintf("%v", r)
// 获取所有 goroutine 的堆栈（注意：buf 需足够大）
buf := make([]byte, 1024*1024) // 1MB 缓冲区，避免截断
n := runtime.Stack(buf, true)
stack := string(buf[:n])
// ✅ 此时 errMsg 和 stack 均可自由处理：
// - 写入结构化日志（如 JSON）
// - 发送到监控系统（如 Sentry、Prometheus Alertmanager）
// - 过滤敏感信息后再落盘
fmt.Printf("PANIC CAUGHT:\n%s\nSTACK TRACE:\n%s\n", errMsg, stack)
}
}()
// 触发 panic
panic("something went wrong")
}⚠️ 注意事项：
- runtime.Stack 返回的堆栈是纯文本快照，不包含 panic 发生位置的源码行号（除非编译时保留调试信息，且运行环境支持）。若需精确定位，建议配合 -gcflags="all=-l"（禁用内联）和符号表使用。
- 缓冲区大小需预估充足（如上例使用 1MB），否则堆栈会被截断——可通过循环扩容或先调用 runtime.Stack(nil, true) 获取所需长度（Go 1.18+ 支持）。
- runtime.Stack(_, true) 开销较大（遍历所有 goroutine），仅应在 panic 处理路径中使用，切勿在高频逻辑中调用。
- 若只需当前 goroutine 堆栈（更轻量），将 true 改为 false 即可，适用于简单错误诊断场景。
总结：通过 recover + runtime.Stack 组合，你完全掌控 panic 输出的生成与流向，摆脱对 stderr 重定向的依赖，实现日志隔离、错误归因、可观测性增强等生产级需求。这是构建健壮 Go 服务的关键实践之一。
