工作池核心是限流而非简单并发，需用固定worker数+带缓冲channel控制任务队列与结果传递，避免goroutine泛滥、阻塞和panic导致卡死。
Go 里用 channel 实现工作池，核心不是“怎么写个 for + goroutine”，而是控制并发数、避免 goroutine 泛滥、正确处理任务完成与错误传递。直接上无缓冲 channel 做任务队列 + 固定数量 worker，是最稳的起点。
为什么不能直接为每个任务起 goroutine
HTTP 请求量突增时，go handleTask(task) 可能在几秒内启动上万 goroutine，内存暴涨、调度开销大，甚至触发 OOM。Go 调度器不保证高并发下公平性，大量 goroutine 竞争 runtime.mheap 会卡顿。
工作池本质是「限流」：用固定数量的 worker 复用 goroutine，靠 channel 排队任务。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 用
make(chan Task, 0)（无缓冲）但没配够 worker，导致 sender 永久阻塞 - worker 里没 recover，panic 后整个 pool 卡死
- 任务完成信号用
done chan struct{}但没 close 或漏读，主 goroutine 无法退出
标准三组件结构：jobs、results、worker 函数
典型结构包含三个 channel：
-
jobs := make(chan Task, 100)：带缓冲，防主 goroutine 因 worker 暂时忙而阻塞 -
results := make(chan Result, 100)：同样带缓冲，避免 worker 因结果来不及消费而卡住 - worker 函数从
jobs读，处理后发到results，需包一层defer func() { recover() }()
启动 N 个 worker：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
for w := 0; w < 4; w++ {
go worker(jobs, results)
}注意：worker 数量不是越多越好。CPU 密集型任务建议设为 runtime.NumCPU()；IO 密集型可适当提高（如 8–16），但需压测验证。超过 32 通常收益递减。
如何安全关闭工作池并等待所有任务完成
不能简单 close(jobs) 就完事——已有 goroutine 正在读，close 后再读会 panic；也不能等 len(results) 达到任务数，因为 channel 长度不可靠。
正确做法是用 sync.WaitGroup：
- 发送任务前
wg.Add(1) - 每个 worker 处理完一个任务后
wg.Done() - 所有任务发完后，另起 goroutine
wg.Wait()，然后close(results)
示例关键片段：
var wg sync.WaitGroup
for _, task := range tasks {
wg.Add(1)
jobs <- task
}
go func() {
wg.Wait()
close(results)
}()主 goroutine 从 results range 读取，range 自动在 close 后退出。
实际项目中容易被忽略的细节
真实场景比 demo 复杂得多：
- 任务可能超时：
select套time.After，超时后把 error 发到 results，别让 worker 卡死 - 需要取消全部任务：
context.Context传入 worker，每次读jobs前检查ctx.Err() - 结果乱序问题：如果顺序重要，别依赖发送顺序，加
Task.ID字段，主 goroutine 收集后按 ID 排序 - 内存泄漏风险：task 结构体含大字段（如 []byte），worker 处理完记得置空或用指针传参避免拷贝
最常出问题的不是 channel 语法，而是边界控制——谁 close、谁 wait、谁 recover、谁负责超时和取消。这些点漏掉一个，上线后就是半夜告警。
