




runtime/debug 提供 Stack()、SetTraceback()、ReadMemStats() 等低开销诊断工具:Stack() 获取当前 goroutine 堆栈快照,SetTraceback() 控制 panic/trace 符号粒度,ReadMemStats() 采集内存统计(触发 STW),GC trace 需通过 GODEBUG 环境变量启用。
Stack()
runtime/debug.Stack() 返回当前所有 goroutine 的堆栈快照([]byte),常用于 panic 捕获、健康检查或诊断死锁。它不触发 GC,开销低,但注意:它只抓取调用时正在运行/阻塞的 goroutine,不会包含已退出或尚未启动的。
常见误用是直接打印而忽略截断——默认最多返回 4MB 数据,超出部分被静默丢弃。若需完整堆栈,应提前用 SetTraceback("all") 提升符号完整性,并配合 os.Stdout.Write() 分块写入。
fmt.Printf("[%s]\n%s", time.Now(), debug.Stack())
debug.PrintStack() 更轻量(直接输出到 stderr)SetTraceback()
runtime/debug.SetTraceback() 影响 panic 和 stack trace 中显示的帧数与符号信息粒度。参数可选 "none"、"single"(默认)、"all" 或数字(如 "20")。设为 "all" 后,trace 会包含 runtime 内部函数(如 gopark、semacquire),对分析调度阻塞、锁竞争至关重要。
但副作用明显:开启后每次 panic 输出体积增大 3–5 倍,且部分 runtime 函数无导出符号,可能显示为 ???。线上服务通常保持默认,仅在复现特定 hang 问题时临时启用。
立即学习“go语言免费学习笔记(深入)”;
Stack() 生效,不影响已发生的 panic-ldflags="-s -w"),"all" 效果大打折扣ReadMemStats()
runtime/debug.ReadMemStats() 是唯一能精确获取实时内存分配状态的标准方式,返回 runtime.MemStats 结构体。它会触发一次 stop-the-world 的 GC 统计快照,因此调用频率过高(如每秒多次)会导致 STW 累积延迟升高。
关键字段包括:Alloc

HeapInuse(堆内存占用)、NumGC(GC 次数)、PauseNs(最近 GC 暂停耗时纳秒数组)。注意:PauseNs 是环形缓冲区,长度固定为 256,旧数据会被覆盖。
Alloc 判断内存泄漏——它包含未释放但可达的对象;应结合 LiveObjects(Go 1.21+)或 pprof 分析NextGC 和 Alloc 可能不严格对应runtime/debug 包本身**不提供开启 GC trace 的函数接口**。实际启用需通过环境变量:GODEBUG=gctrace=1(输出每次 GC 摘要)或 GODEBUG=gctrace=2(附加详细标记-清除阶段日志)。输出直接写到 stderr,无法重定向到自定义 writer。
这个设计容易让人误以为有类似 SetGCLog() 的 API。真正可控的方式只有启动时设置环境变量,或用 pprof.Lookup("goroutine").WriteTo() 配合定时 dump,但后者不包含 GC 时间线。
GODEBUG 对子进程无效,需在 exec 前显式继承gctrace=1 每秒输出几十行,易淹没关键日志,建议搭配 grep "gc \d\+" 过滤runtime/debug 是把窄而锋利的刀——它不做抽象封装,所有能力都紧贴运行时内核暴露点。用得好能快速定位 goroutine 泄漏、GC 频繁、栈爆炸,但每个函数背后都有明确的调度代价和语义边界,跳过文档直奔示例很容易掉进 STW 或符号缺失的坑里。