go中打印调用栈需正确使用runtime.stack、debug.printstack和runtime.caller：runtime.stack需手动管理缓冲区与all参数；debug.printstack仅适合panic兜底；runtime.caller仅获单层位置，非完整堆栈。
Go 里打印调用栈不是靠 stack 这个词本身——标准库没有叫 stack 的函数或类型，真正能用的只有 runtime.Stack、debug.PrintStack 和 runtime.Caller 这三类机制。选错方法会导致日志没堆栈、panic 捕获失败、或者性能骤降。
runtime.Stack(buf, all) 怎么用才不踩坑
这是最可控的方式，但必须手动管理缓冲区大小和 all 参数含义：
-
all = false：只抓当前 goroutine 的栈，适合常规错误定位；all = true会包含所有 goroutine，调试死锁/协程泄漏时有用，但输出量大、开销高 - 缓冲区太小会截断堆栈（
runtime.Stack返回值n等于len(buf)就说明不够）；常见写法是循环扩容，比如先make([]byte, 4096)，不够就翻倍重试 - 别直接
fmt.Printf("%s", buf)—— 如果buf末尾没 \n，终端可能不换行；建议用string(buf[:n])后显式加\n
debug.PrintStack() 是快捷键，但只在 panic 里可靠
debug.PrintStack() 内部就是调用 runtime.Stack(os.Stderr, false)，但它默认输出到 os.Stderr，且不返回字符串，无法自定义格式或注入上下文：
- 在
defer func() { recover(); debug.PrintStack() }()里用没问题，适合快速兜底 - 如果想把堆栈塞进结构化日志（比如 zap 的
With字段），它就不适用——必须用runtime.Stack自己取字符串 - 注意：它不会自动 flush
os.Stderr，某些容器环境可能延迟显示，加os.Stderr.Sync()更稳妥
runtime.Caller(skip) 获取单层调用位置，别误当完整堆栈
runtime.Caller(1) 只返回「谁调了我」这一层的文件、行号、函数名，不是调用链：
- 常见错误是以为
Caller(2)或Caller(3)能拿到更上层——但 skip 值依赖调用深度，封装多层后极易偏移，不可靠 - 真要拼完整链路，得用
runtime.Callers+runtime.FuncForPC手动遍历，代码冗长，仅限诊断工具内部使用 - 日常记录错误位置，
log.SetFlags(log.Llongfile | log.LstdFlags)更轻量，但只打触发log那一行，不反映调用路径
panic 场景下 recover + Stack 组合最容易漏掉关键信息
很多人写 recover() 后只打印 err.Error()，丢掉了调用栈：
- 必须在
recover()后立刻调用runtime.Stack（或debug.PrintStack），否则 goroutine 已开始清理栈帧，再取就空了 - 别在 recover 里做耗时操作（如网络请求、复杂 JSON 序列化），否则可能掩盖原始 panic 时机，让堆栈指向错误位置
- 如果用了
errors.WithStack（如github.com/pkg/errors），记得用%+v格式化输出，否则堆栈不展开
真正难的不是“怎么打出堆栈”，而是判断该打哪一层、打多少、打给谁——是写进日志字段？还是发到告警通道？或是仅开发期 console 输出？缓冲区大小、goroutine 范围、是否同步 flush，这些细节在压测或线上环境会立刻暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
