Golang中何时适合用worker pool？errgroup.SetLimit是否使其冗余？

问题翻译 #

在Go语言中，过去大家通常会用各种实现的Worker（goroutine）池来限制并发数。今年夏天，golang.org/x/sync/errgroup包新增了errgroup.SetLimit功能，它可以把组内活跃goroutine的数量限制为最多n个。那么，Worker Pool模式在大多数场景下是不是已经没必要了？如果不是的话，哪些场景更适合用Worker Pool模式，而非errgroup.SetLimit或者直接用无限制的goroutine？

Worker Pool并没有被errgroup.SetLimit完全替代，两者适用场景有明显差异，以下是Worker Pool依然更合适的核心场景：

1. 持续/批量任务流的goroutine复用 #

如果你的任务是持续产生的（比如从消息队列、TCP连接源源不断接收任务），Worker Pool的goroutine可以长期复用，避免频繁创建销毁goroutine的调度成本——虽然goroutine本身轻量，但高频创建还是会带来内存波动和调度开销。而errgroup.SetLimit是针对一次性任务组的限制，任务跑完goroutine就退出，无法复用。

2. 任务需要共享高成本资源 #

如果每个任务依赖初始化成本高的资源（比如数据库连接、HTTP客户端实例、复杂计算上下文），Worker Pool可以让每个worker预先持有这些资源，任务过来直接使用，不用每次都初始化。比如每个worker绑定一个DB连接，避免频繁建立断开连接的开销。errgroup.SetLimit的每个goroutine都是独立的，要复用资源得额外做共享控制，反而繁琐。

3. 需要精细的任务调度与管控 #

Worker Pool可以实现灵活的调度逻辑：比如给任务设置优先级、动态调整worker数量、暂停/恢复任务处理、监控worker负载等。而errgroup.SetLimit仅做简单的并发数限制，没有这些扩展能力。

4. 统一处理任务结果或错误 #

如果需要对所有任务结果做聚合、排序，或对错误做集中处理（比如统计错误类型、重试失败任务），Worker Pool可以通过结果通道统一收集，逻辑更清晰。errgroup的核心特性是任一任务出错时取消所有任务（默认行为），或等待全部任务完成后收集错误，对结果的精细化处理不如Worker Pool便捷。

5. 兼容现有代码或团队约定 #

很多成熟Go项目已经有稳定的Worker Pool实现，团队成员熟悉其用法和行为。若现有Worker Pool已封装业务逻辑，没必要为了errgroup.SetLimit重构代码，反而增加风险。

适合用errgroup.SetLimit的场景 #

反过来，errgroup.SetLimit更适合一次性批量任务，比如批量处理文件、调用一批API，且你需要：

• 自动处理goroutine取消（某个任务出错时，终止其他所有任务）
• 简单的并发数限制，无需额外调度逻辑
• 快速实现代码，不想手写Worker Pool的复杂逻辑

纯goroutine的适用场景 #

纯无限制goroutine仅适合任务量极小、并发不会失控的场景（比如十几个以内的任务），否则容易导致内存耗尽或调度压力过大。

内容的提问来源于stack exchange，提问作者rtuna