runtime/debug 提供 Stack()、SetTraceback()、ReadMemStats() 等低开销诊断工具：Stack() 获取当前 goroutine 堆栈快照，SetTraceback() 控制 panic/trace 符号粒度，ReadMemStats() 采集内存统计（触发 STW），GC trace 需通过 GODEBUG 环境变量启用。
获取当前 Goroutine 堆栈信息用 Stack()
runtime/debug.Stack() 返回当前所有 goroutine 的堆栈快照（[]byte），常用于 panic 捕获、健康检查或诊断死锁。它不触发 GC，开销低，但注意：它只抓取调用时正在运行/阻塞的 goroutine，不会包含已退出或尚未启动的。
常见误用是直接打印而忽略截断——默认最多返回 4MB 数据，超出部分被静默丢弃。若需完整堆栈，应提前用 SetTraceback("all") 提升符号完整性，并配合 os.Stdout.Write() 分块写入。
- 调试时建议加时间戳：
fmt.Printf("[%s]\n%s", time.Now(), debug.Stack()) - 生产环境慎用：高频调用会引发内存抖动，尤其在高并发 HTTP handler 中
- 若只需当前 goroutine，改用
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语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 生效时机：调用后对后续 panic /
Stack()生效，不影响已发生的 panic - 无法在 CGO 调用栈中回溯 C 函数，仅限 Go 层
- 交叉编译时若未保留调试信息（如用
-ldflags="-s -w"），"all"效果大打折扣
读取内存统计必须用 ReadMemStats()
runtime/debug.ReadMemStats() 是唯一能精确获取实时内存分配状态的标准方式，返回 runtime.MemStats 结构体。它会触发一次 stop-the-world 的 GC 统计快照，因此调用频率过高（如每秒多次）会导致 STW 累积延迟升高。
关键字段包括：Alloc（当前已分配字节数）、HeapInuse（堆内存占用）、NumGC（GC 次数）、PauseNs（最近 GC 暂停耗时纳秒数组）。注意：PauseNs 是环形缓冲区，长度固定为 256，旧数据会被覆盖。
- 监控场景推荐每 10–30 秒采样一次，避免干扰正常调度
- 不要用
Alloc判断内存泄漏——它包含未释放但可达的对象；应结合LiveObjects（Go 1.21+）或 pprof 分析 - 该函数不保证原子性：结构体字段在复制过程中可能跨 GC 周期，
NextGC和Alloc可能不严格对应
写入 GC 跟踪日志要配环境变量而非 API
runtime/debug 包本身**不提供开启 GC trace 的函数接口**。实际启用需通过环境变量：GODEBUG=gctrace=1（输出每次 GC 摘要）或 GODEBUG=gctrace=2（附加详细标记-清除阶段日志）。输出直接写到 stderr，无法重定向到自定义 writer。
这个设计容易让人误以为有类似 SetGCLog() 的 API。真正可控的方式只有启动时设置环境变量，或用 pprof.Lookup("goroutine").WriteTo() 配合定时 dump，但后者不包含 GC 时间线。
-
GODEBUG对子进程无效，需在 exec 前显式继承 - 日志格式无稳定契约，不同 Go 版本间可能变化（如 Go 1.22 新增 sweep phase 细分）
- 高频率 GC 场景下，
gctrace=1每秒输出几十行，易淹没关键日志，建议搭配grep "gc \d\+"过滤
runtime/debug 是把窄而锋利的刀——它不做抽象封装，所有能力都紧贴运行时内核暴露点。用得好能快速定位 goroutine 泄漏、GC 频繁、栈爆炸，但每个函数背后都有明确的调度代价和语义边界，跳过文档直奔示例很容易掉进 STW 或符号缺失的坑里。 
