Go runtime 不提供高阶快照，仅暴露底层原始信息；NumGoroutine() 和 ReadMemStats() 易误用，后者触发 STW；GC 控制函数有严格限制；无稳定 Goroutine ID；GOMAXPROCS 控制 P 数而非 CPU 核心数。
Go 的 runtime 包不提供“运行时状态快照”这类高阶抽象，它暴露的是底层调度、内存、Goroutine 等原始信息——直接调用能拿到数据，但多数字段含义模糊、变化频繁、依赖 Go 版本，生产环境慎用。
获取当前 Goroutine 数量和内存统计
最常被误用的两个函数是 runtime.NumGoroutine() 和 runtime.ReadMemStats()。前者返回当前存活的 Goroutine 总数（含系统 goroutine），后者填充一个 runtime.MemStats 结构体，包含堆分配、GC 次数等字段。
注意：MemStats 中的 Alloc、TotalAlloc 是字节数，不是对象个数；NumGC 是 GC 发生次数，不是“正在 GC”；调用 ReadMemStats 会触发一次 stop-the-world 小停顿（通常微秒级，但高频率调用会影响延迟敏感服务）。
- 避免在 hot path（如 HTTP handler 内部）每请求调用
ReadMemStats - 若只需估算堆大小，可改用
debug.ReadGCStats获取 GC 时间线，开销更低 -
NumGoroutine()对排查 goroutine 泄漏有用，但需配合 pprof 确认泄漏源头
var m runtime.MemStats
runtime.ReadMemStats(&m)
fmt.Printf("heap alloc: %v KB, num goroutines: %d\n", m.Alloc/1024, runtime.NumGoroutine())
控制 GC 行为与触发时机
runtime.GC() 是唯一能主动触发垃圾回收的函数，但它不阻塞到 GC 完成——只阻塞到 GC “启动完成”，实际清扫可能仍在后台进行。而 debug.SetGCPercent() 可动态调整 GC 触发阈值（默认 100），设为 -1 则禁用 GC（仅测试用）。
立即学习“go语言免费学习笔记（深入）”；
关键限制：这些控制对 runtime/pprof 或 net/http/pprof 暴露的指标无直接影响；GC 行为受 GOGC 环境变量全局控制，代码中设置仅对当前程序生效。
-
runtime.GC()在单元测试中可用于验证对象是否被及时回收（配合testing.T.Cleanup） - 线上服务禁止在请求处理中调用
runtime.GC()，易引发毛刺 -
debug.SetGCPercent(50)会让 GC 更激进，但可能增加 CPU 开销，需压测验证
获取 Goroutine ID 和栈信息
Go 官方不提供获取当前 Goroutine ID 的导出函数（goroutine id 是内部实现细节，且在 Go 1.14+ 协程复用模型下 ID 不稳定）。试图通过 runtime.Stack() 解析栈字符串提取 ID 属于 hack 行为，极易因格式变更失效。
真正可用的是：runtime.Stack(buf []byte, all bool) —— 将所有或当前 goroutine 的栈迹写入 buf，返回实际写入长度。常用于 panic 日志或诊断工具。
- 传
false时只捕获当前 goroutine 栈，开销小；传true会遍历所有 goroutine，耗时随 goroutine 数量线性增长 - 缓冲区
buf需预先分配足够空间（如 64KB），否则返回 0 并提示buf is too small - 不要用栈字符串做业务逻辑判断（如“跳过某类 goroutine”），解析不可靠
buf := make([]byte, 64*1024)
n := runtime.Stack(buf, false)
fmt.Printf("current goroutine stack:\n%s", buf[:n])
理解 GOMAXPROCS 和 P 的实际影响
runtime.GOMAXPROCS(n) 设置的是可同时运行用户级 Go 代码的操作系统线程数（即 P 的数量），不是 CPU 核心数。它不改变已存在的 M（OS 线程）数量，只影响新创建的 P 分配。
常见误区：认为设为 1 就能“串行执行”，其实网络 I/O、timer、sysmon 等仍可能触发并发；设为大于 CPU 核心数也不一定提升吞吐，反而加剧上下文切换。
- Go 1.5+ 默认
GOMAXPROCS等于 CPU 核心数，一般无需手动设置 - 容器环境中若未配置
CPU quota，runtime.NumCPU()返回的是宿主机核心数，可能导致过度并发 - 修改后无法回滚，且对已启动的 goroutine 无即时效果，仅影响后续调度
真正需要关注的是 runtime/pprof 和 expvar 提供的指标，它们封装了 runtime 底层数据并做了稳定性保障；直接读 runtime 字段就像直接读 /proc/self/stat —— 能看到，但得自己懂每一列什么意思，还随时可能变。
