debug.stack() 经常只输出 runtime.goexit 或内容不全，因其底层固定使用 4kb 临时缓冲区，超长即静默截断，且返回切片未拷贝，可能被 gc 回收导致乱码或空内容。
直接用 debug.Stack() 就能拿到当前 goroutine 的完整堆栈字节切片，但别直接转字符串后乱用——它不检查缓冲区大小，内部用的是固定 4KB 临时分配，超长就截断，且返回的切片可能被 GC 回收导致日志乱码。
为什么 debug.Stack() 经常只输出 runtime.goexit 或内容不全
它底层调用的是 runtime.Stack(buf, false)，但自己分配一个 4096 字节的 []byte。一旦实际堆栈超过这个长度（比如嵌套深、函数名长、有大量 goroutine 本地变量打印），就会静默截断，不报错也不提示。你看到的只有最顶几层，甚至只剩 runtime.goexit 这一行。
- 不是 bug，是设计如此：为快速调试而生，不保证完整性
- 不会 panic，也不会返回错误，只默默丢数据
- 返回的
[]byte是从 runtime 临时分配的，没做 copy，后续 GC 可能回收其底层数组——如果你把它存进日志异步写入，大概率写出来是空或乱码
debug.PrintStack() 适合什么场景，又有什么硬伤
它把堆栈直接写到 os.Stderr，绕过日志系统，零配置、无内存管理负担，开发期埋点最省事。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 只输出当前 goroutine，看不到其他协程状态
- 输出无格式、无时间戳、无 caller 标识，混在日志里容易被忽略
- 不能重定向，无法接入 structured logger（如 zap、zerolog）
- 线上禁止使用：stderr 不受日志采样/限流控制，高频调用会冲垮磁盘 I/O
如何安全地在 recover() 中记录完整堆栈
panic 恢复后想留痕，必须立刻拷贝堆栈内容，不能依赖返回值直接传给异步日志。
- 别写
string(debug.Stack())—— 底层切片可能被回收 - 正确做法：用
buf := make([]byte, 1024*1024)预分配 1MB，再调runtime.Stack(buf, false) - 拿到返回长度
n后，立刻string(buf[:n])转成独立字符串 - 如果
n == len(buf)，说明又被截断了，可考虑重试加大缓冲区（但线上建议直接放弃，改用 pprof 接口）
线上环境该用什么替代 runtime.Stack(buf, true)
传 true 会 STW，上万 goroutine 下耗时可达百毫秒，监控可能报警、请求超时、调度器卡顿。这不是“慢”，是“危险”。
- 优先走
/debug/pprof/goroutine?debug=2HTTP 接口，它用流式写入+采样机制，开销低得多 - 若需程序内触发，用
pprof.Lookup("goroutine").WriteTo(w, 2)，自己控制 writer（比如写文件或发 HTTP body） - 绝对不要在 HTTP handler、gRPC 方法、定时任务主路径里调
runtime.Stack(..., true) - 真要诊断泄漏，配合
pprof.Lookup("goroutine").Count()做阈值告警，而不是每次 dump 全量
真正难的不是“怎么打堆栈”，而是判断该打哪一层、打多大、打完怎么用。缓冲区大小、STW 影响、GC 安全性、日志集成——这些细节不处理好，堆栈信息本身就成了故障诱因。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
