panic默认只打印顶层位置，需在defer+recover中立即调用runtime.Stack(buf, false)捕获完整堆栈；debug.PrintStack()直接输出stderr，不适合生产日志。
panic发生时如何捕获完整堆栈（非recover场景）
默认情况下，panic 触发后程序会打印简略堆栈（只到调用panic的那一行），丢失中间调用链。这不是bug，而是Go运行时的默认行为——它只在终止前输出“顶层panic位置”，不展开完整的goroutine栈帧。
要拿到完整堆栈，必须在recover中主动获取并格式化。但注意：仅靠recover()本身不会返回堆栈，它只返回panic值；堆栈需额外调用debug.PrintStack()或runtime.Stack()。
-
debug.PrintStack()直接打印到os.Stderr，适合调试，但无法捕获为字符串 -
runtime.Stack(buf []byte, all bool)可将堆栈写入字节切片，推荐用于日志记录 - 若在
defer中调用，必须确保recover()已执行成功，否则runtime.Stack()仍可能返回空或截断内容
使用runtime.Stack获取可处理的堆栈字符串
runtime.Stack() 是最可控的方式，它能生成带goroutine ID、函数名、文件行号的完整文本堆栈。关键参数all=false表示只抓当前goroutine（常用），all=true会包含所有goroutine（日志体积大，一般不用）。
常见错误是传入过小的buf导致截断。Go文档明确建议：先用0长度切片试探所需容量，再分配足够空间。
立即学习“go语言免费学习笔记（深入）”；
defer func() {
if r := recover(); r != nil {
var buf [4096]byte
n := runtime.Stack(buf[:], false)
stack := string(buf[:n])
log.Printf("panic recovered: %v\n%s", r, stack)
}
}()
为什么debug.PrintStack()不适合生产日志
debug.PrintStack() 看似简单，但它绕过日志系统直接写os.Stderr，导致三类问题：
- 无法控制输出格式（比如加时间戳、traceID）
- 无法重定向到文件或远程服务（如Loki、ELK）
- 在多goroutine panic时，多个
debug.PrintStack()输出会交错，难以归属
更隐蔽的问题是：它在recover之后调用，但Go运行时此时已开始清理goroutine状态，某些低层帧（如调度器相关）可能被省略——而runtime.Stack()在panic上下文中调用更稳定。
goroutine泄漏导致堆栈不全的典型场景
如果panic发生在由go关键字启动的goroutine中，且该goroutine未被recover，主goroutine退出后整个程序终止，其他goroutine的堆栈根本不会被打印。这时你看到的“无堆栈”不是工具问题，而是程序提前结束了。
解决方法只有两个：
- 所有
go语句都配对defer+recover（尤其网络handler、定时任务） - 用
sync.WaitGroup或context确保goroutine完成或超时退出，避免“静默消失”
没有全局panic hook机制，Go的设计哲学就是让错误显式传播，所以堆栈完整性完全依赖你是否在每个可能panic的goroutine里做了防护。
