非 panic 路径应禁用 debug.PrintStack()，因其无返回值、输出到 stderr 且无上下文；推荐用 debug.Stack() 获取字节切片后定制日志，或 runtime.Caller() + 日志 flag 轻量记录调用位置。
别在非 panic 路径里直接用 debug.PrintStack()——它输出到 os.Stderr、无时间戳、不带上下文，混在日志里根本分不清是哪次调用打的，而且容器环境下 stderr 可能被丢弃，你根本看不到。
什么时候真能用 debug.PrintStack() 做非 panic 调试
它只适合开发期临时探针：你想确认“此刻这个 goroutine 到底是从哪几层函数跳进来的”，又不想改代码结构、不依赖 error、也不关心格式。
- 必须在明确可控的单个 goroutine 内使用（比如 main 函数开头、某个 handler 入口、或单元测试 setup 里）
- 不能塞进高频路径（如 HTTP 中间件、循环体、RPC 请求处理主干），否则 stderr 冲刷、性能毛刺、日志污染全来
- 确保 stderr 没被重定向丢弃——本地跑没问题，但 systemd 或 k8s pod 里要加
os.Stderr.Sync()才可能立刻看到 - 别指望它帮你区分协程：它永远只打当前 goroutine，你在 goroutine A 里调，看不到 goroutine B 的栈
debug.PrintStack() 和 debug.Stack() 的关键区别在哪
前者是“甩锅式输出”，后者才是“可编程取栈”——生产环境唯一靠谱的非 panic 堆栈获取方式就是 debug.Stack()。
-
debug.PrintStack()没返回值，硬写到os.Stderr，没法塞进zap.Error()或log.WithField() -
debug.Stack()返回[]byte，你可以：string(debug.Stack())转字符串、截断前 2048 字节防日志爆炸、加time.Now().Format()打时间戳、甚至 base64 编码后上报监控 - 注意：
debug.Stack()底层调用的是runtime.Stack(buf, false)，所以它也只取当前 goroutine；要抓全部协程得自己调runtime.Stack(buf, true)
非 panic 场景下更稳的替代方案
如果只是想记录“谁调了我”，用 runtime.Caller() + 日志 flag 就够了，比堆栈轻量得多。
立即学习“go语言免费学习笔记（深入）”；
- 启动时加
log.SetFlags(log.Llongfile | log.LstdFlags)，所有log.Printf()自动带文件+行号，不干扰调用链，开销极小 -
runtime.Caller(1)能拿到上一层调用位置，但 skip 值会随封装层数漂移——比如你包了一层 wrapper，Caller(1)就指向 wrapper，不是原始调用方 - 真要拼完整链路？别手写
runtime.Callers+runtime.FuncForPC，太容易出错；优先考虑用github.com/pkg/errors包装错误，再用%+v输出，它会在 error 上附着调用帧
最常被忽略的一点：非 panic 路径下打堆栈，不是为了“看全”，而是为了“对齐上下文”。你真正需要的往往不是 50 行栈，而是「这次请求 ID 对应的入口 goroutine 栈」——这时候用 debug.Stack() + request ID 字段，比盲目打 PrintStack() 有用十倍。
