runtime.NumGoroutine() 是监控协程数最直接方式，需配合阈值检查、信号量限流、pprof定位及worker pool等结构化手段防控协程爆炸。
使用 runtime.NumGoroutine() 是监控 Go 程序中当前活跃协程数量最直接的方式，但它本身不防止协程爆炸——真正起作用的是配合它做主动检查、限流和资源控制。
基础用法：实时获取协程数
调用 runtime.NumGoroutine() 返回当前正在运行或处于等待状态（如阻塞在 channel、锁、syscall）的 goroutine 总数。它开销极小，可高频调用：
- 适合在日志、健康检查接口或定时任务中采集快照
- 注意：该数值包含 runtime 内部使用的 goroutine（如 GC、netpoll），通常占 5–20 个，需结合业务基线判断异常
- 示例：log.Printf("current goroutines: %d", runtime.NumGoroutine())
关键场景：在启动新协程前做守门人
不能只“看”不“拦”。应在创建 goroutine 的入口处加阈值判断，避免无节制 spawn：
- 定义安全上限（例如 5000），每次
go f()前检查：if runtime.NumGoroutine() > 5000 { log.Warn("too many goroutines, skip task") } - 更稳妥的做法是结合信号量（如
semaphore.NewWeighted(100)）统一管理并发度，比单纯数数字更可靠 - 对 HTTP handler、消息消费循环等高危入口尤其要加保护，避免请求洪峰触发协程雪崩
配合 pprof 定位泄漏源头
单纯告警不够，需快速定位谁在疯狂启协程：
立即学习“go语言免费学习笔记（深入）”；
- 启用
pprof：在服务中注册net/http/pprof，访问 /debug/pprof/goroutine?debug=2 查看完整堆栈 - 重点关注长时间处于
select、chan receive或time.Sleep的 goroutine，它们可能已“挂起”却未退出 - 用
go tool pprof分析火焰图，识别高频创建 goroutine 的函数路径
长期治理：用结构化方式替代裸 go
预防比监控更重要。从编码习惯上减少失控风险：
- 避免在 for 循环里直接写
go doWork(i)，改用 worker pool 模式（固定 N 个消费者处理任务队列） - 所有异步操作必须有超时或上下文控制：go func(ctx context.Context) { ... }(ctx)，并在内部监听
ctx.Done() - 用
errgroup.Group替代手动管理一组 goroutine，天然支持 cancel 和错误传播
