goroutine泄漏比性能差更致命，需用WaitGroup管理生命周期、带缓冲channel做任务队列、固定数量goroutine消费任务；WaitGroup仅计数不保证执行状态，需配合done channel或context确认退出；channel缓冲大小决定背压能力，应据任务耗时、内存限制等合理设置。
goroutine 泄漏比性能差更致命
不加控制地 go func() {...}() 启动大量 goroutine，轻则内存暴涨、调度延迟升高，重则触发 OOM 或被系统 kill。真正需要的不是“并发越多越好”，而是“可控、可等待、可复用”的执行单元。直接上 sync.WaitGroup + 手动限流容易出错；用第三方 pool（如 panjf2000/ants）又可能引入隐式依赖和行为差异。最稳妥的方式是组合原生工具：用 WaitGroup 管理生命周期，用带缓冲 channel 做任务队列，用固定数量的 goroutine 消费任务。
WaitGroup 不能替代信号同步
WaitGroup 只负责计数，不保证任务已开始执行或已安全退出。常见错误是：wg.Add(1) 后立刻 go func() { defer wg.Done(); doWork() }()，但主 goroutine 在 wg.Wait() 前就结束——此时子 goroutine 仍可能在运行，且无任何上下文约束。正确做法是：
- 所有
wg.Add()必须在启动 goroutine 前完成（不能在 goroutine 内部调用） - 若任务需共享状态（如结果切片），必须加锁或使用
chan传递，避免竞态 -
wg.Wait()后不代表所有 goroutine 已退出，只是计数归零；若需确认退出，应配合done chan struct{}或 context
channel 缓冲区大小决定吞吐与背压行为
用 make(chan Task, N) 构建任务队列时，N 不是并发数，而是待处理任务的积压上限。设太小（如 1）会导致生产者频繁阻塞；设太大（如 10000）会吃光内存却无法提升实际并发。合理值取决于：
- 任务平均执行时间（越长，越需更大缓冲防生产者卡住）
- 内存限制（每个任务结构体大小 × 缓冲数 ≈ 占用内存）
- 是否允许丢弃超负荷任务（此时可用
select { case ch ）
实践中，从 runtime.NumCPU() 的 2–4 倍起步测试较稳妥。
立即学习“go语言免费学习笔记（深入）”；
固定 worker 数量比动态伸缩更可控
所谓 “goroutine pool” 并不需要动态创建/销毁 goroutine。启动固定数量（如 runtime.NumCPU()）的长期 worker 即可：
func startWorkers(taskCh <-chan Task, wg *sync.WaitGroup, numWorkers int) {
for i := 0; i < numWorkers; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for task := range taskCh {
task.Run()
}
}()
}
}注意：taskCh 是只读 channel，关闭后所有 worker 自动退出；wg.Done() 放在循环外，确保每个 worker 只减一次计数；不要在循环内重复 wg.Add(1) —— 那会破坏计数逻辑。
真正的复杂点在于：如何把结果安全回传？别用全局变量，优先选 chan Result 配合独立 collector goroutine；如果任务有 ID，用 map[TaskID]Result 加 sync.RWMutex 也行，但要注意 map 非并发安全。
