runtime.NumGoroutine()数值本身无业务意义，因其包含3–5个固定runtime内部协程；区分“活跃”与“假活跃”需结合pprof堆栈、g.waitreason阻塞原因及生命周期变化，而非仅看atomicstatus=="waiting"——该状态实为阻塞态，并非空闲。
直接看 runtime.NumGoroutine() 数值没用，它包含 runtime 内部的 3–5 个固定 goroutine，不能反映业务是否异常；真要分析活跃状态，得结合堆栈上下文、阻塞原因和生命周期三者交叉判断。
怎么区分“活跃”和“假活跃”的 goroutine
Go 官方定义的“活跃 goroutine”包括：正在运行、就绪队列中等待调度、因 channel/锁/网络 I/O 而阻塞的 goroutine——也就是说，waiting 状态也算活跃。这和直觉相反，容易误判。
-
atomicstatus == "waiting"不代表空闲，可能卡在chan receive或semacquire上，需查g.waitreason - 系统 goroutine（如
netpoll、timerproc）始终存在，ID 通常很小（ - finalizer goroutine 和 idle goroutine 不计入
NumGoroutine()，但会出现在runtime.GoroutineProfile()的全量列表里
用 pprof 抓取真实堆栈时参数别写错
pprof.Lookup("goroutine").WriteTo(os.Stdout, 1) 和 ...WriteTo(..., 2) 差异极大：前者只输出顶层函数（如 main.main），后者才展开完整调用链，漏掉后者基本没法定位阻塞点。
- 生产环境慎用
WriteTo(..., 2)：每个 goroutine 平均多占 2–5 KiB 内存，1 万个 goroutine 就是 30+ MiB 临时缓冲 - 调试时优先用
http://localhost:6060/debug/pprof/goroutine?debug=2，比手写WriteTo更稳，且支持 gzip 压缩 - 别依赖
runtime.Stack(buf, true)的true参数——它只控制是否打印所有 goroutine，不控制堆栈深度；深度由 buf 大小决定
阻塞分析（block profile）比 goroutine 数更准
一个 goroutine 卡在 sync.Mutex.Lock 上 10 秒，NumGoroutine() 只显示 +1，但 pprof.Lookup("block").WriteTo(..., 1) 会明确标出阻塞时长和竞争热点。
立即学习“go语言免费学习笔记（深入）”；
- 必须提前开启：在
main()开头加runtime.SetBlockProfileRate(1)，否则默认 rate=0，啥也抓不到 - rate=1 表示每次阻塞都记录，开销大；rate=1e6 更适合生产，表示平均每 100 万纳秒阻塞才记一次
- 输出里关键字段是
cycles（纳秒级）和blocking（阻塞 goroutine 数），不是看堆栈行数多少
为什么 goroutine 泄漏常被忽略
泄漏 goroutine 很少表现为“数量持续上涨”，更多是“某类堆栈反复出现且 never exit”。比如所有泄漏 goroutine 都停在 io.ReadFull + net.Conn.Read，说明连接没关或超时没设。
- 用 goleak 时注意：它默认过滤
testing.*和runtime.*，但如果你的 worker 启动函数叫startWorker，而它调用了time.Sleep，goleak 可能误判为“正常等待” - 自定义过滤要写全路径：
goleak.IgnoreTopFunction("yourpkg.(*Worker).run")，只写run会漏匹配 - 最隐蔽的泄漏：goroutine 启动后立即 panic，但 defer 里的 close(channel) 没执行，导致接收方永久阻塞——这种不会出现在 goroutine profile 的“创建处”，得靠 block profile 或 trace 找
真正难的不是抓数据，而是把 g.waitreason、堆栈末尾函数、channel 类型（unbuffered/buffered）、锁持有者这四条线索串起来；多数人卡在只看数字，不看上下文。
