直接用 goroutine 会崩是因为不加限制地启动大量 goroutine 会导致调度争抢、内存暴涨，甚至触发 OOM；关键在控制同时运行数量而非启动总数。
为什么直接用 goroutine 会崩？
不加限制地启动成百上千个 goroutine，轻则触发调度器争抢、内存暴涨，重则触发 runtime: out of memory 或被系统 OOM kill。Go 的并发不是“越多越好”，而是“够用且可控”。关键不在“启多少”，而在“同时跑几个”。
常见错误是写成这样：
for _, item := range items {
go process(item) // ❌ 没有节流，items 一万个就起一万个 goroutine
}这本质上不是批处理，是并发轰炸。
用带缓冲 channel 实现最简 WorkerPool
核心思路：用一个 chan struct{} 当“许可证桶”，容量即最大并发数；每个 worker 启动前先从桶里取一张“票”，处理完再还回去。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 定义池结构体，包含
jobs（输入任务 channel）、results（输出结果 channel）、sem（信号量 channel）和workers数量 -
sem初始化为make(chan struct{}, maxConcurrent)，别用int类型——避免整数溢出和竞争 - 每个 worker 循环中先执行
<-sem阻塞拿许可，处理完再sem <- struct{}{}归还 - 务必在
defer或显式位置关闭results，否则接收方可能永远阻塞
示例关键片段：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
sem := make(chan struct{}, 10) // 最多 10 并发
for i := 0; i < 10; i++ {
go func() {
for job := range jobs {
<-sem // 拿票
result := process(job)
results <- result
sem <- struct{}{} // 还票
}
}()
}用 errgroup + semaphore 更稳妥
原生 errgroup.Group 不自带并发控制，但配合 golang.org/x/sync/semaphore 就很干净。它比手写 channel 更健壮：支持带权重的获取、可取消、能返回具体错误。
使用场景：
- 需要统一捕获第一个 panic 或 error
- 任务耗时差异大，想避免某个长任务卡死整个池
- 后续可能扩展为带 context 取消的批处理
注意点：
-
semaphore.Weighted的Acquire是阻塞操作，必须传入非零context，推荐用context.Background()或带超时的 - 每个
Acquire后必须配对Release，哪怕发生 panic，建议用defer sem.Release(1) - 权重设为
1即等价于传统工作池；设为2表示该任务占两个并发槽位
简例：
sem := semaphore.NewWeighted(5)
g, ctx := errgroup.WithContext(context.Background())
for _, job := range jobs {
job := job // 避免循环变量复用
g.Go(func() error {
if err := sem.Acquire(ctx, 1); err != nil {
return err
}
defer sem.Release(1)
process(job)
return nil
})
}
_ = g.Wait()别忽略任务分发与结果收集的边界问题
并发度控制只是冰山一角。真正线上出问题的，往往是任务分发没关 channel、结果读取没做超时、或 panic 没 recover 导致 worker 消失。
容易踩的坑：
-
jobschannel 必须由生产者 close，否则 worker 会永远range等下去；别指望靠并发数自动结束 - 接收
results时，如果任务数不确定或部分失败，别用固定for i := 0; i < len(items); i++，改用for range+select超时 - worker 内部没包
recover()，一个 panic 就少一个 worker，池子慢慢变“残废” - 大量小任务时，channel 通信开销可能反超处理本身，这时应考虑批量打包（如每 10 个合成一个 job）再投递
复杂点从来不在“怎么限并发”，而在于“谁负责关 channel、谁负责收 panic、谁保证结果不丢”。这些地方漏一个，压测时就掉链子。
