goroutine泄漏比数量失控更危险，关键在生命周期管理而非单纯限数；应避免无条件启动、绑定context、用chan struct{}实现信号量控制并发。
goroutine 泄漏比数量失控更危险
Go 里没有“协程池”原语，硬套线程池思路容易翻车。真正要防的不是 go func() 太多，而是 goroutine 启动后卡在 I/O、channel 等待或忘了收尾，持续占用栈内存和调度器资源。一个泄漏的 goroutine 比一千个秒级退出的更伤。
控制数量只是表象，本质是明确生命周期——谁启、谁停、超时怎么处理、错误怎么传递。
- 别用全局计数器 +
sync.WaitGroup手动增减，容易漏Done()或 panic 跳过清理 - 避免在循环里无条件
go f()，尤其配合time.Sleep或重试逻辑时，极易指数级堆积 - HTTP handler、定时任务、消息消费这类长时服务，必须绑定 context 并检查
ctx.Done()
用 semaphore（信号量）做轻量级并发限制
标准库没 semaphore，但用 chan struct{} 实现最稳妥，零依赖、无锁、语义清晰。它不管理 goroutine，只管“同时最多跑几个”，把调度权留给业务逻辑本身。
示例：限制 HTTP 客户端并发请求数
// 限制最多 5 个并发请求
sem := make(chan struct{}, 5)
<p>for <em>, url := range urls {
sem := http.Get(u)
// 处理 resp...
}(url)
}</em></p>
-
cap(sem)就是最大并发数，调整它比改代码逻辑快得多 - 务必用
defer func() { ，不能写成 <code>defer （语法错） - 如果 goroutine 可能 panic，
defer仍会执行，但需搭配 recover 或日志确认是否真释放了
context.WithTimeout + select 是防止 goroutine 挂起的关键组合
光限数量不够，还得设“截止时间”。否则一个慢接口卡住，整个信号量队列就堵死，新请求永远拿不到 sem。
正确做法：每个 goroutine 自带超时，且超时后主动退出并释放信号量。
sem := make(chan struct{}, 10)
for _, job := range jobs {
select {
case sem
-
select的default分支让调用方可控，避免因等待sem导致主线程卡住 -
doWork函数内部必须用select监听ctx.Done()，否则超时无效 - 不要在 goroutine 里用
time.Sleep替代context，它无法被外部中断
别碰第三方“goroutine pool”库，除非你清楚它怎么处理 panic 和 context
很多开源池子用 recover 捕获 panic、用 channel 做任务队列、甚至自己实现调度器——这反而增加了不确定性。Go 调度器本就高效，额外抽象层常带来隐蔽延迟和内存泄漏点。
真实项目里，95% 的场景用信号量 + context 就够了。剩下 5%，往往是业务逻辑本身没拆清责任边界。
- 查
runtime.NumGoroutine()只能看瞬时数量，看不出哪些 goroutine 卡在哪儿；用pprof/goroutine才能定位挂起点 - 所有池子都无法解决“函数内部死循环”或“channel 发送不接收”这类问题，得靠代码审查和测试
- 如果必须用池（比如固定 worker 处理 Kafka 消息），优先选
workerpool这类极简实现，拒绝带“自动重试”“优雅关闭”等复杂特性的库
实际压测时，goroutine 数量波动正常，但持续增长超过 1000 就该立刻查 pprof；信号量满不是瓶颈信号，是下游服务已不可用的告警。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
