必须立即限制 goroutine 数量并确保 channel 消费端受控：循环启协程需加限流（如 worker pool），channel 消费端必须监听 ctx.Done() 或及时关闭，否则必致调度器过载、栈内存暴涨、GC 频繁 STW。
goroutine 瞬间暴涨到几万，程序变慢甚至 OOM 怎么办
这不是“可能”出问题，而是必然——调度器记账开销飙升、栈内存疯涨、GC 频繁 STW、pprof 里 runtime.gopark 占比超 70%，都是明确信号。根本原因往往就两点：循环里无节制启协程，或 channel 消费端没关/没接 ctx.Done()。
- HTTP handler 中写
for _, req := range requests { go handle(req) }？10 万条数据就是 10 万个 goroutine，立刻踩中调度器红线 - 用
select { case 等 channel，但 ch 永远不写、也不关，这个 goroutine 就卡死在 park 状态，持续占内存和调度元数据 - 忘记调
resp.Body.Close()，底层连接复用失败，HTTP client 内部悄悄起新 goroutine 管理连接，越积越多
用带缓冲的 chan struct{} 做信号量，最简限流方案
别碰无缓冲 channel 做并发控制——它本质是同步点，所有 goroutine 抢一个 channel，锁竞争剧烈，反而更慢。带缓冲的 chan struct{} 是轻量、无锁、标准库原生支持的限流手段。
- 定义：
sem := make(chan struct{}, 100)表示最多 100 个并发任务同时执行 - 启动前占位：
sem ；完成后释放： - 注意：必须确保每条路径（包括 panic、error 早 return）都执行释放，否则会漏归还，导致“假死限流”
- 不推荐用
time.Sleep或轮询模拟信号量，那是反模式，徒增调度负担
改用 worker pool 复用 goroutine，适合长生命周期任务
如果每个任务耗时几十毫秒以上，或者需要复用数据库连接、HTTP client 等资源，worker pool 比信号量更优——它把 goroutine 当“线程池”用，避免反复创建销毁开销。
- 核心结构：一个任务 channel（如
jobs := make(chan Job, 128)），N 个长期运行的 worker goroutine 从里面取任务 - worker 数量建议设为
runtime.NumCPU() * 2 ~ 4，压测后微调；I/O 密集可稍多，CPU 密集不宜超过GOMAXPROCS - 务必配合
sync.WaitGroup和close(jobs)实现优雅关闭，否则for job := range jobs会永远阻塞 - 开源库
ants提供了带超时回收、动态扩容的成熟实现，可直接集成，但简单场景手写 20 行足够
用 pprof 和 runtime.NumGoroutine() 定位泄漏源头
靠猜没用。goroutine 泄漏往往静默发生，直到某次发布后内存缓慢上涨、请求延迟升高才被发现。
立即学习“go语言免费学习笔记（深入）”；
- 加一行日志：
log.Printf("active goroutines: %d", runtime.NumGoroutine())，定期打点观察趋势 - 启用 pprof：在 HTTP 服务中注册
net/http/pprof，访问/debug/pprof/goroutine?debug=2查看完整堆栈，重点关注卡在chan receive、select、syscall的 goroutine - 配合
GODEBUG=schedtrace=1000观察调度器行为，若看到大量 G 长时间处于runnable但得不到 P，说明并发数已超调度能力 - 别忽略 context：所有 goroutine 启动时必须传入
ctx，并在select中监听ctx.Done()，这是防止泄漏的底线
真正难的不是写对一两个 goroutine，而是在业务逻辑层层嵌套、第三方库调用链深不可测时，仍能保证每个 goroutine 都有明确的退出路径和资源归属。这点，工具帮不上忙，只能靠设计时就把它刻进接口契约里。
