任务数很多时应该每任务一个协程还是固定工作池

先给选择结论：任务总量小、明确有界，而且每个任务占用的外部资源可控时，每任务一个 goroutine 通常最简单；任务持续到达、数量可能无界，或数据库连接、远端接口、内存等资源有硬上限时，应使用创建前限流或固定工作池。二者的核心差别不是“能不能并发”，而是谁限制正在运行的任务数、排队任务数，以及取消后由谁回收。

Go 中准确的名称是 goroutine。它比操作系统线程轻量，初始栈很小且可按需增长，但并不等于零成本。每个 goroutine 仍可能持有栈、闭包变量、定时器、连接、请求体和等待关系；如果输入速度长期高于处理速度，数量最终会反映到内存、调度和下游压力上。

Go 官方地址：https://go.dev/

先按任务边界做选择

不要先问“工作池是不是更专业”，先看任务来源和资源约束。下面这张表可以作为默认判断。

Go 官方的 Effective Go 给出了同样的资源边界：只用带缓冲 channel 当信号量，但仍为每个请求先创建 goroutine，会让等待中的 goroutine 数量继续增长；可以把额度获取放在 go 语句之前，或者启动固定数量的处理 goroutine 从请求 channel 读取任务。

每任务一个 goroutine 适合什么情况

每任务一个 goroutine 的优势是代码贴近业务：一个任务对应一次函数调用、一个结果和一个退出点。只要任务集合有明确上限，这种写法通常比通用工作池更容易理解，也不会引入额外的任务队列协议。

下面的最小示例适合“输入切片已经在内存中，任务数可控，全部完成后统一返回”的批处理。结果通道使用与任务数相同的容量，避免任务结束时因为收集端尚未读取而阻塞；WaitGroup 只负责关闭结果通道，不负责传递错误。

package batch

import (
	"context"
	"fmt"
	"sync"
)

type Job struct {
	ID int
}

type Result struct {
	JobID int
	Value string
	Err   error
}

func process(ctx context.Context, job Job) (string, error) {
	// 在真实任务中，应把 ctx 继续传给数据库或 HTTP 调用。
	select {
	case 

这段代码并没有限制并发。如果 jobs 只有 100 个，而且每个任务都只是短小计算或可控 I/O，它很合适；如果 jobs 可能达到几十万，并且每个任务都在等待同一个数据库连接池，那么大量 goroutine 只是从“等待任务”变成“等待连接”，压力没有消失。

只限制执行量时，在创建 goroutine 前拿额度

有些场景不需要完整工作池：输入是一个有限切片，任务函数结构已经很清楚，只想把同时执行数限制为 32。此时可以用带缓冲 channel 作为信号量，但关键是先拿到额度，再创建 goroutine。如果先 go 再在函数内部拿额度，几十万个任务仍会变成几十万个等待中的 goroutine。

package batch

import (
	"context"
	"fmt"
	"sync"
)

func RunWithLimit(ctx context.Context, jobs []Job, limit int) error {
	if limit 

这个方案的排队位置在提交循环：额度满时，提交者阻塞，后续任务尚未创建 goroutine。它适合单次批处理，但不适合多个生产者持续提交，也没有显式队列长度、任务优先级和长期 worker 生命周期。出现这些需求时，固定工作池更清晰。

固定工作池的最小可用结构

固定工作池把并发控制拆成两个数字：workers 决定同时处理多少任务，jobs channel 的容量决定允许多少任务排队。队列满时生产者阻塞，这就是背压。它让系统在过载时变慢，而不是无界增加 goroutine 和内存。

下面的实现保留输入顺序对应的结果位置，支持父级取消，并在第一个处理错误出现时取消尚未开始或仍在执行的工作。提交者负责关闭 jobsCh，等待者负责关闭 out，worker 都不关闭共享通道。

package pool

import (
	"context"
	"errors"
	"fmt"
	"sync"
)

type Job struct {
	ID int
}

type Result struct {
	JobID int
	Value string
}

type indexedJob struct {
	index int
	job   Job
}

type indexedResult struct {
	index  int
	result Result
	err    error
}

func process(ctx context.Context, job Job) (Result, error) {
	// 模拟可取消工作；真实代码要把 ctx 传递到下游调用。
	select {
	case 

这个模板选择“首错取消全部”，适合任务共同组成一次批处理。如果任务彼此独立，某个失败不应影响其他任务，可以不调用 cancel()，改为把所有错误按任务索引收集。错误策略必须由业务决定，不能由工作池偷偷决定。

workers 和队列容量怎么设置

没有适用于所有任务的固定公式，先按瓶颈类型给出起点，再用等待时间、吞吐和错误率调整。

CPU 密集型任务不应简单把 worker 数设为任务数。Go 官方 runtime 文档说明，GOMAXPROCS 限制可以同时执行用户级 Go 代码的 CPU 数；当前运行时还可能结合逻辑 CPU、CPU affinity 和 Linux cgroup CPU 配额选择默认值。以 runtime.GOMAXPROCS(0) 作为起点，通常比写死机器核数更贴近进程实际可用并行度。

package config

import "runtime"

func CPUWorkers() int {
	// 查询运行时当前允许的并行度，不修改 GOMAXPROCS。
	workers := runtime.GOMAXPROCS(0)
	if workers 

I/O 密集型可以高于 GOMAXPROCS，因为很多 goroutine 大部分时间在等待；但上限应来自下游容量，而不是“goroutine 很轻”。如果数据库连接池只有 20 个可用连接，把 worker 设成 500 通常只会增加 480 个等待者。对于远端 API，还要把服务端限流、客户端连接池、超时和重试预算一起考虑。

队列容量也不是越大越稳定。大队列能吸收短暂突发，却会隐藏持续过载并增加排队延迟。常见起点是 worker 数的 1 到 4 倍，然后观察队列占用率和提交阻塞时间。若队列长期接近满载，应降低输入、扩容处理能力或拒绝任务，而不是无限加长队列。

兼容性与生命周期注意事项

Go 1.22 调整了 for 循环变量语义，循环体每次迭代获得自己的变量。为了让示例在更早版本也不踩闭包捕获问题，前面的代码仍显式写了 job := job。这行在新版本中可以省略，但保留它不会改变意图。

sync.WaitGroup 只解决“等待一组任务结束”，不携带结果，不传播取消，也不会自动关闭 channel。传统兼容写法是先 Add，在 goroutine 中 defer Done，最后 Wait。不要在 Wait 已经可能返回后再添加首批任务，否则关闭通道的 goroutine 可能过早执行。

Go 官方 pipeline 文章强调，消费者提前退出时，必须通知上游发送者停止。工作池同样需要这一条：所有可能阻塞的 channel 发送和接收都应能观察 ctx.Done()，否则调用方已经超时，worker 仍可能永久卡在发送结果上。

• 只由生产者关闭任务通道，因为只有生产者知道不会再提交。
• 只由等待全部 worker 的协调者关闭结果通道。
• worker 不关闭共享通道，避免多个发送者竞争关闭。
• 外部调用必须有超时或取消入口，内部调用继续传递同一个 Context。
• 任务函数若持有文件、响应体或连接，使用 defer 在每次任务结束时释放。

常见误区

goroutine 很轻，所以每任务一个一定没问题吗？

不一定。轻量只说明单个创建成本较低，不表示数量可以无界增长。闭包、栈、计时器、阻塞关系和任务持有的业务对象都会占资源；更关键的是，下游容量往往比 goroutine 数更早到达上限。

在 goroutine 内部用 semaphore 算限制数量吗？

它只限制同时进入临界区的数量，不限制已经创建但正在等待 semaphore 的 goroutine 数。若目标是控制 goroutine 数，应在 go 语句之前获取额度，或直接用固定 worker。

固定工作池会不会一定更快？

不会。工作池的主要价值是容量边界和背压，不是自动提升速度。任务很少时，队列和协议反而增加复杂度；任务耗时差异很大时，单一 FIFO 池还可能让短任务排在长任务后面。

worker 数应该等于 CPU 核数吗？

CPU 密集型可从 GOMAXPROCS 附近起步；I/O 密集型通常可以更高，但必须受数据库连接、远端配额、文件句柄和内存限制。最终数字应由压测和生产指标决定。

怎么判断池子是否设置合理？

至少记录当前 worker 数、活动任务数、队列长度与容量、提交阻塞时间、任务处理时长、错误率、超时率和 goroutine 总数。队列长期满说明持续过载；队列总为空但延迟仍高，瓶颈可能在任务函数内部或下游。

最后的决策清单

• 任务集合已知且不大：优先每任务一个 goroutine。
• 集合有界，只需要并发上限：在创建 goroutine 前获取额度。
• 输入持续或可能无界：使用固定 worker 和有界队列。
• 下游资源有限：并发数不超过真实容量，避免把等待从一处搬到另一处。
• 任务共同成败：首错取消并等待全部退出；任务彼此独立：逐项收集错误。
• 必须明确谁关闭任务通道、谁关闭结果通道，以及取消如何传到最底层。

一句话总结：每任务一个 goroutine 是简单的生命周期模型，固定工作池是显式的容量模型。当任务数量和资源消耗都有上界时，选择简单方案；当到达速率、排队量或下游资源可能失控时，用有界工作池把压力写进程序结构。