不加限制启动大量 goroutine 会耗尽内存或压垮下游服务，因每个至少占 2kb 栈空间且调度开销大；worker pool 通过固定数量长期运行的 goroutine 消费任务队列实现并发控制。
为什么直接用 goroutine 会出问题
不加限制地启动成百上千个 goroutine，容易耗尽内存或打爆下游服务。Go 的调度器虽轻量，但每个 goroutine 至少占 2KB 栈空间，加上频繁创建/销毁的调度开销，实际负载远超预期。常见现象是程序卡顿、OOM 被系统 kill，或者 HTTP 服务返回 502 Bad Gateway（上游连接池被打满）。
Worker Pool 的核心不是“起多少”，而是“同时最多跑几个”。关键在用固定数量的长期运行 goroutine 消费任务队列，而非为每个任务新建一个。
用 channel + for-select 实现基础 Worker Pool
最简可行结构：一个任务 channel（jobs），一组固定数量的 worker goroutine，每个 worker 在循环中从 jobs 取任务并执行。注意必须用 for-select 配合 range 或 close 控制退出，否则 worker 会阻塞在接收端无法结束。
-
jobs建议设缓冲区（如make(chan Job, 100)），避免生产者因无人消费而阻塞 - worker 数量由你控制并发上限，例如
numWorkers := 4，就起 4 个 goroutine - 任务完成信号建议用单独的
donechannel（chan struct{}），别用sync.WaitGroup混合管理，易漏Done()
jobs := make(chan Job, 100)
done := make(chan struct{})
<p>for w := 0; w </p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill8661" title="Golang Uber Dig"><img
src="https://img.php.cn/upload/skill/000/000/081/179215391842073.jpg" alt="Golang Uber Dig" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill8661" title="Golang Uber Dig" class="overflowclass">Golang Uber Dig</a>
<p class="overflowclass">使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等</p>
</div>
<a rel="nofollow" href="/xiazai/skill8661" title="Golang Uber Dig" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><p>// 发送任务
for _, j := range tasks {
jobs </p><p>// 等待所有 worker 结束
for i := 0; i </p><h3>如何安全传递参数并避免闭包陷阱</h3><p>上面示例里直接在 goroutine 内部用 <code>job</code> 变量，实际会捕获循环变量引用，导致所有 worker 处理同一个 <code>job</code>（最后那个）。这是 Go 新手高频踩坑点。</p>
- 正确做法：把
job作为参数传入匿名函数，或在循环内定义新变量（job := job） - 如果任务需要携带上下文（如
context.Context），不要在 worker 启动时固定传入，而应在每个job.Process()内部处理，否则超时逻辑会失效 - 避免在
job结构体里存指针指向外部大对象，防止 GC 延迟——worker 池生命周期长，容易意外延长对象存活时间
要不要用第三方库？标准库够用但要注意边界
像 golang.org/x/sync/errgroup 或 uber-go/goleak 这类工具不能替代 Worker Pool，它们解决的是错误传播或测试泄漏问题。真正需要并发控制时，标准库的 chan + goroutine 组合已足够，但要注意：
-
chan容量不是并发数！它只是缓冲区大小；并发数 = 启动的 worker 数量 - 如果任务有 I/O 等待（如 HTTP 请求），worker 数可以略高于 CPU 核心数；纯计算型任务则建议 ≤
runtime.NumCPU() - 没有“自动伸缩”机制——想动态调参就得自己加锁管理
numWorkers变量，且要确保正在运行的 worker 不受影响
复杂点在于任务失败重试、优先级队列、或需要统计吞吐量时，得额外加 channel 和状态机。这些不是 Worker Pool 本身的责任，而是业务逻辑该封装的部分。
