必须用固定数量worker+带缓冲channel实现可控并发，因go func()高并发会导致内存暴涨和oom；sync.pool不管理goroutine生命周期，无法解决无限启协程问题，且任务可能丢失。
直接用 go func() 启动协程处理任务，在高并发下必然导致内存暴涨、调度延迟飙升甚至 OOM；必须用固定数量的长期运行 worker + 带缓冲 channel 任务队列来实现可控并发。
为什么不能用 sync.Pool 管理 worker
sync.Pool 是为临时对象（如 []byte）复用设计的，它不管理 goroutine 生命周期，也不提供任务排队、限流或超时能力。把 worker 函数塞进 sync.Pool，只是复用了闭包或结构体，每次仍会新建 goroutine——根本没解决“无限启协程”的问题。
-
sync.Pool.Get()返回的是任意上次存入的对象，无法保证“谁来执行当前任务” - 池中对象可能被 GC 清理，worker 意外消失，任务无声丢失
- 没有
range jobs这样的自然退出机制，关闭逻辑复杂且易漏
如何用 channel + for-select 实现最小可用 worker pool
核心是：启动固定数量的 goroutine，每个都通过 for job := range jobs 持续消费任务；任务提交方只往 jobs channel 发送，不关心执行细节。
- 任务 channel 必须带缓冲，例如
make(chan Job, 100)，否则生产者一发任务就阻塞，失去异步性 - worker 数量建议设为 CPU 核心数的 1.5–2 倍；IO 密集型可更高，CPU 密集型不宜超核数
- 务必在所有任务提交完成后
close(jobs)，否则range jobs永不退出，worker 卡死 - 每个 worker 内部要加
defer recover()，防止单个任务 panic 导致整个 worker 终止
示例关键片段：
func startWorker(jobs <h3>如何安全关闭并等待所有 worker 完成</h3><p>靠 <code>sync.WaitGroup</code> 控制生命周期，但必须严格遵循“先 <code>Add</code>，再 <code>go</code>，传指针”，否则计数失效、<code>Wait()</code> 立即返回。</p>
-
wg.Add(1)必须在go startWorker(...)之前调用，且wg必须以指针形式传入 worker 函数 - worker 内部用
defer wg.Done()，确保无论正常退出还是 panic 都能减计数 - 关闭前先
close(jobs)，再wg.Wait()，顺序反了会导致部分任务未消费 - 不要用
context.WithCancel强行中断range jobs，这会跳过未读完的任务；应让 worker 自然退出
真正难的不是写出让 worker 跑起来的代码，而是让它们在 panic、超时、服务重启、队列满等边界条件下依然不丢任务、不泄露协程、不卡死 channel —— 这些细节全藏在 defer、close 时机和 WaitGroup 的传参方式里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
