协程池是控制资源消耗上界的有效手段，通过固定worker数量和带缓冲channel将并发数锁死，避免文件描述符耗尽、内存暴涨与调度退化；直接go func()启动大量协程极易导致系统崩溃。
直接用 go func() 启动大量协程，在真实业务中基本等于给自己埋雷——不是“能不能”，而是“迟早崩”。协程池不是为了炫技，是为控制资源消耗上界：固定 worker 数量 + 带缓冲 channel，就能把并发数锁死，避免文件描述符耗尽、内存暴涨、调度退化。
为什么不能直接 go doWork()？
看似轻量的 goroutine，堆起来照样压垮系统：
• 每个 goroutine 初始栈 2KB，活跃时可能涨到 8KB+；1000 个就是至少 2MB 内存
• 更致命的是它持有的外部资源：HTTP 连接、DB 连接、文件句柄——这些不共享，且受 OS 限制（如 Linux 默认 1024 fd）
• 10 万个 URL 爬取请求，若不加限制，第 1025 个连接直接报 too many open files
• Go 调度器在成千上万 goroutine 下会明显退化，GC 频次上升，延迟毛刺增多
make(chan Task, queueSize) 缓冲区大小怎么设？
缓冲区不是越大越好，也不是越小越安全，它和 worker 数共同构成资源水位线：
• queueSize 建议设为 capacity * 2 到 capacity * 10（例如 20 个 worker，队列设 200～2000）
• 过小（如设为 0 或 1）：Submit 可能阻塞调用方，尤其在 burst 流量下容易卡死
• 过大：内存占用无节制增长，任务积压导致响应延迟不可控，还可能掩盖下游瓶颈
• 若业务对背压敏感（比如上游是 Kafka consumer），应改用带超时的 select { case p.tasks
如何安全关闭并等待所有任务完成？
只 close(p.tasks) 是不够的——已入队但未执行的任务仍会跑，正在执行的 task 却无法中断：
• 必须配合 sync.WaitGroup：提交前 wg.Add(1)，task 执行完 wg.Done()
• Close() 方法要先关闭 tasks channel，再 wg.Wait()，确保所有已提交任务结束
• 不要在 worker 内部 recover() 吞 panic——错误被静默丢弃，调用方永远不知道任务失败了；应在 task 函数内处理或让 panic 向上传导
• 注意：关闭后不能再调用 Submit，否则触发 panic: send on closed channel
立即学习“go语言免费学习笔记（深入）”；
worker 数设多少才合理？
这不是靠 CPU 核心数拍脑袋定的：
• I/O 密集型任务（HTTP 请求、Redis 查询）：通常设为 runtime.NumCPU() * 2 到 * 4，比如 8 核机器配 16～32 个 worker
• CPU 密集型任务（图像压缩、加密计算）：应接近 runtime.NumCPU()，避免上下文切换开销反超收益
• 真实值必须靠压测确定：观察 QPS、P99 延迟、内存 RSS、goroutine 数（runtime.NumGoroutine()）、fd 使用量（lsof -p $PID | wc -l）
• 没有银弹参数——同一套配置在本地开发机跑得飞起，在 K8s 里可能因资源限制瞬间 OOM
真正难的从来不是写完那几十行代码，而是把 capacity、queueSize、context.WithTimeout 这三者在真实流量下调平衡。线上出问题时，90% 的“协程池失效”其实源于参数没随环境变化而重估，而不是实现本身有 bug。
