runtime.numgoroutine() 返回当前程序中正在运行或处于等待状态的 goroutine 总数，包括用户创建和 runtime 内部协程，是瞬时、无锁、低开销的整数快照。
runtime.NumGoroutine() 返回什么值
runtime.NumGoroutine() 返回当前程序中**正在运行或处于等待状态的 goroutine 总数**，包括已启动但尚未结束、被阻塞在 channel、mutex、syscall 或 sleep 中的 goroutine。它不区分“用户创建”和“runtime 内部使用”的 goroutine，比如 net/http 的监听协程、gc 相关的 worker 协程都会被计入。
这个数字是瞬时快照，调用即返回，无锁、开销极低，适合高频采样（如每秒一次）。
- 值为 1 表示只有 main goroutine 在跑，通常意味着程序几乎空闲
- 值持续 >1000 不一定异常，但若伴随 CPU/内存上涨，就得查泄漏
- 它不告诉你哪些 goroutine 在哪卡住——只是总数，别指望靠它定位具体问题
怎么安全地在生产环境打印 goroutine 数量
直接 log.Println(runtime.NumGoroutine()) 没问题，但更实用的是嵌入指标暴露逻辑，比如通过 HTTP 接口或 Prometheus metrics。
常见错误是把 runtime.NumGoroutine() 放在日志里狂打（比如每毫秒一次），这本身会引入调度扰动；也有人误以为数值突增=bug，其实可能是临时 burst 请求触发的正常扩容。
- 推荐方式：用
promhttp暴露为Gauge，配合prometheus.NewGaugeFunc - 避免在高并发 handler 里频繁调用并拼接字符串日志，改用结构化日志 + 采样（如每 5 秒记录一次）
- 不要在 defer 或 panic 恢复路径里依赖它做判断——此时 goroutine 状态可能已不稳定
为什么 pprof 查到的 goroutine 数和 NumGoroutine() 不一致
这是最常被问懵的点：runtime.NumGoroutine() 和 go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2 显示的内容根本不是一回事。
NumGoroutine() 是一个整数；而 pprof 的 /goroutine?debug=2 输出的是**所有 goroutine 的栈跟踪快照**，默认只显示非空闲（non-idle）的 goroutine —— 它过滤掉了大量 runtime 内部的 idle worker，比如 runtime.gopark 在 netpoll 上休眠的那些。
- pprof 默认行为等价于加了
?debug=1（只显示正在运行/可运行的），不是全量 - 想看“全部”，得用
/goroutine?debug=2，但即使这样，某些刚创建还没调度的 goroutine 可能仍不出现 -
NumGoroutine()的值 ≥ pprof debug=2 显示的行数，差值通常是 idle netpoll workers 或 GC mark assist 协程
goroutine 泄漏时 NumGoroutine() 会一直涨吗
不一定。泄漏的 goroutine 如果最终都阻塞在某个 channel receive 上，且没人 close 或 send，那它们会长期存在，NumGoroutine() 会稳定在一个偏高的值，不再上涨——但它也不会降下来。
真正危险的是“持续创建+不释放”的模式，比如在 for 循环里启 goroutine 却没控制生命周期，这时数字会线性或指数增长，直到 OOM。
- 观察重点不是“是否上涨”，而是“是否在业务逻辑结束后仍不回落”
- 搭配
pprof/goroutine?debug=2对比不同时间点的栈，找重复出现的相同调用链 - 注意 timer-based goroutine：比如
time.AfterFunc启动后没被 cancel，也会滞留
数字本身没意义，关键是你知道它在哪涨、为什么没掉、以及它对应的真实资源消耗。监控阈值设成固定值很容易误报，不如结合请求量做比率（如 goroutines / QPS）来判断异常。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
