debug.Stack() 返回当前 goroutine 调用栈而非错误源头，仅反映调用时刻的栈帧；需在错误创建处包装堆栈（如 pkg/errors.Wrap），生产环境应使用 debug.Stack() 而非 debug.PrintStack()，并注意性能开销与 goroutine ID 缺失问题。
debug.Stack() 返回的是当前 goroutine 的堆栈，不是错误源头
很多人误以为 debug.Stack() 能“回溯到 panic 发生点”，其实它只捕获调用它的那一时刻、当前 goroutine 的完整调用栈。如果错误是层层返回上来的（比如从底层 io.Read → 中间层 decode → 顶层 handler），debug.Stack() 记录的是 handler 处理错误时的位置，不是 io.Read 出错的那一行。
- 真正想定位原始错误位置，得在错误生成/首次传播处包装堆栈，比如用
github.com/pkg/errors.Wrap()或自定义WithStack() - 若只能改日志逻辑、不能动错误构造路径，
debug.Stack()至少能告诉你「谁最后处理了这个错误」，配合log.SetFlags(log.Lshortfile)可交叉验证 - 别在 defer recover 里无条件调用——如果 recover 捕到的是别人抛出的 error（非 panic），
debug.Stack()和问题无关
生产环境必须用 debug.Stack() 而不是 debug.PrintStack()
debug.PrintStack() 直接写到 os.Stderr，而生产服务常把 stderr 重定向或丢弃（比如 systemd 服务默认不透出 stderr 到 journal，或容器日志驱动过滤掉非 stdout 流）。你看到的日志里只有 “panic recovered: …”，没有堆栈，大概率是这个原因。
-
debug.Stack()返回[]byte，可直接转成 string 塞进结构化日志字段，例如：logger.Error("panic caught", "stack", string(debug.Stack())) - 若用 zap、zerolog 等库，建议把 stack 字段设为
Stringer类型或预格式化，避免 JSON 序列化时被截断或转义混乱 - 注意：返回的字节切片包含换行符和缩进，别用
fmt.Sprintf("%s", ...)再套一层——容易多出空格或换行错位
goroutine ID 不在 debug.Stack() 结果里，需额外采集
debug.Stack() 输出纯调用链，不带 goroutine ID、状态（running/waiting）、启动位置等上下文。线上排查时，经常要区分「是哪个协程卡住」或「多个协程同时 panic」。
- 用
runtime.Stack(buf, true)替代——第二个参数设为true会 dump 所有 goroutine，开头含 goroutine ID 和状态；设为false才等价于debug.Stack() - 但
runtime.Stack(buf, true)开销更大，生产环境慎用；建议只在 SIGUSR1 信号 handler 或诊断接口中触发，而非 panic 日志路径 - 更轻量的做法：在日志里加
goroutineID()辅助函数（基于runtime.Stack解析首行数字），和debug.Stack()结果一起输出
高频调用 debug.Stack() 会导致 CPU spike 和 GC 压力
每次调用 debug.Stack() 都要遍历当前 goroutine 栈帧、分配内存、做符号解析。压测或高并发场景下，如果在热路径（比如每请求都 log.Error + Stack）里调用，可观测到明显 CPU 升高和短时分配激增。
立即学习“go语言免费学习笔记（深入）”；
- 仅保留在异常路径：recover 分支、error != nil 且 severity == ERROR 的日志分支
- 避免在循环内、中间件通用日志、或健康检查 handler 里调用
- 如果日志系统支持采样（如 zap 的 sampled core），可对 stack 字段单独设低采样率（如 0.01），既保留线索又控开销
debug.Stack() 当作“万能错误溯源工具”——它解决不了错误传播链缺失的问题，只是帮你看清最后一站。真正稳定的堆栈追踪，得靠从错误创建那一刻就注入上下文，而不是等到崩溃才补救。 
