并发是Golang的核心优势，goroutine的创建成本极低，一个进程轻松跑起几十万个goroutine。但并发任务批量处理并不是简单粗暴地开一批goroutine就完事了：没有数量控制会瞬间耗尽内存或压垮下游接口，没有错误处理会让任务失败无从得知，没有结果收集则拿不到处理产出。这篇文章汇总几种常用且成熟的Golang并发批量处理方案，从基础到进阶逐一给出可运行的代码，帮助你根据实际场景选择合适的方式。
方案一：goroutine配合sync.WaitGroup实现基础并发
最直接的思路是：每个任务一个goroutine，用sync.WaitGroup等待所有任务完成。这种方式写法简单，适合任务数量可控、任务本身是纯计算型（不依赖外部资源）的场景。
package main
import (
"fmt"
"sync"
)
func process(task int) {
// 模拟任务处理
fmt.Printf("处理任务 %d 完成\n", task)
}
func main() {
tasks := make([]int, 100)
for i := range tasks {
tasks[i] = i
}
var wg sync.WaitGroup
for _, t := range tasks {
wg.Add(1)
go func(task int) {
defer wg.Done()
process(task)
}(t)
}
wg.Wait()
fmt.Println("全部任务处理完成")
}</code>注意上面的代码把循环变量t作为参数传入了goroutine闭包。如果直接在闭包里引用外层的循环变量，在Go 1.22之前的版本中会出现经典的变量捕获问题，多个goroutine可能拿到同一个值。虽然Go 1.22之后循环变量语义已经改为每次迭代新建变量，但显式传参依然是更稳妥的写法，兼容旧版本代码时尤其重要。
这种方案的缺点也很明显：没有并发数量上限。如果任务是调用HTTP接口或写数据库，一万个任务同时发出请求，对端服务很可能直接熔断。所以涉及外部资源时，必须引入限流机制，也就是下面要讲的工作池模式。
方案二：带缓冲channel实现固定大小的工作池
工作池（Worker Pool）是控制并发数最经典的模式：预先启动固定数量的worker goroutine，从任务channel中取任务处理，主协程负责投递任务并等待结束。并发数由worker数量决定，不会随着任务量增长而失控。
package main
import (
"fmt"
"sync"
)
func worker(id int, jobs <-chan int, results chan<- string, wg *sync.WaitGroup) {
defer wg.Done()
for job := range jobs {
// 模拟耗时处理
results <- fmt.Sprintf("worker %d 处理了任务 %d", id, job)
}
}
func main() {
const numWorkers = 5
const numJobs = 100
jobs := make(chan int, numJobs)
results := make(chan string, numJobs)
var wg sync.WaitGroup
for i := 1; i <= numWorkers; i++ {
wg.Add(1)
go worker(i, jobs, results, &wg)
}
for j := 1; j <= numJobs; j++ {
jobs <- j
}
close(jobs) // 关闭任务通道，worker退出循环
wg.Wait()
close(results) // 所有worker结束后再关闭结果通道
for r := range results {
fmt.Println(r)
}
}这个例子有几个关键细节值得展开。第一，jobs通道设置了缓冲，主协程投递任务时不会被阻塞，如果缓冲不够大，投递会自然背压（blocking backpressure），这其实也是一种天然的流控手段。第二，close(jobs)必须在投递完成后调用，worker中for job := range jobs才会正常退出。第三，results必须在wg.Wait()之后、即所有worker都结束时才能关闭，否则正在写结果的worker会触发向已关闭通道发送数据的panic。
工作池的并发数设置需要根据下游承受能力来定。经验值是先压测下游的QPS上限，再按照并发数等于目标QPS乘以平均响应时间来估算，比如下游能扛1000 QPS、单请求平均耗时50毫秒，那么50个worker就能打满且不会超载。
方案三：使用errgroup统一管理错误和并发控制
标准库golang.org/x/sync/errgroup是对WaitGroup的增强封装，最大的优势是：任一任务返回错误即可感知，还能用SetLimit一行代码限制并发数，代码量比手写工作池少得多。
package main
import (
"context"
"fmt"
"golang.org/x/sync/errgroup"
)
func fetch(ctx context.Context, id int) error {
// 模拟可能失败的任务
if id == 7 {
return fmt.Errorf("任务 %d 处理失败", id)
}
return nil
}
func main() {
tasks := make([]int, 100)
for i := range tasks {
tasks[i] = i
}
g, ctx := errgroup.WithContext(context.Background())
g.SetLimit(10) // 最多10个并发
for _, id := range tasks {
id := id // Go 1.22前需要，之后可省略
g.Go(func() error {
return fetch(ctx, id)
})
}
if err := g.Wait(); err != nil {
fmt.Println("批量处理出现错误:", err)
return
}
fmt.Println("全部任务成功")
}errgroup.WithContext返回的ctx会在首个错误发生时被取消，任务内部可以通过ctx.Done()感知并及时中止，避免失败后其余任务还在白白消耗资源。这个特性在调用外部API时特别有用：把ctx透传给HTTP请求，一旦某次请求出错，其余进行中的请求会立刻取消。
需要注意errgroup只保留第一个错误，后续错误会被丢弃。如果业务上需要收集全部失败任务，可以配合一个带互斥锁的切片，或者定义自己的错误聚合结构，在任务函数内部记录每个失败项，最后统一输出报表。
方案四：分批处理配合信号量控制大批量任务
当任务量达到几十万甚至上百万时，除了限流，还可以采用分批（batch）策略：每批处理固定数量，一批完成再处理下一批。Golang 1.20新增的semaphore包（golang.org/x/sync/semaphore）提供了基于权重的信号量，也可以用缓冲channel模拟，实现更简洁。
package main
import (
"context"
"fmt"
"time"
)
func processBatch(ctx context.Context, batch []int) error {
sem := make(chan struct{}, 20) // 信号量：最多20个并发
done := make(chan error, len(batch))
for _, item := range batch {
sem <- struct{}{} // 获取信号量，满了就阻塞
go func(i int) {
defer func() { <-sem }() // 释放信号量
time.Sleep(100 * time.Millisecond)
done <- nil
}(item)
}
// 等待本批全部完成
for range batch {
if err := <-done; err != nil {
return err
}
}
return nil
}
func main() {
tasks := make([]int, 1000)
for i := range tasks {
tasks[i] = i
}
batchSize := 100
for start := 0; start < len(tasks); start += batchSize {
end := start + batchSize
if end > len(tasks) {
end = len(tasks)
}
if err := processBatch(context.Background(), tasks[start:end]); err != nil {
fmt.Println("批次失败，中止:", err)
return
}
fmt.Printf("批次 %d-%d 完成\n", start, end)
}
}信号量模式与工作池的区别在于：工作池是固定worker常驻，信号量是任务动态创建但总量受控。信号量写法更灵活，不需要预先划分任务通道，尤其适合任务在运行时动态产生、总数不确定的场景。分批的好处则是每批之间有天然的节奏点，便于插入进度上报、失败重试、检查点保存等逻辑。
此外还有一点容易踩坑：超时控制。无论用哪种方案，都建议在最外层用context.WithTimeout包一层，并给每个任务传递ctx。否则一旦某个任务卡死（比如网络请求hang住），整个批量处理会永久阻塞。同时开启debug.SetTracebacks或定期输出进度日志，能帮你快速定位是哪个任务拖慢了整体。
方案选择建议与总结
面对不同场景，可以这样选型：任务数量少且是纯内存计算，直接用WaitGroup；任务需要调用外部服务且要控制并发上限，优先选errgroup加SetLimit，代码最少且错误处理完善；任务量巨大、需要进度管理和失败重试，采用分批加信号量的组合；需要复用连接、worker初始化成本高（如每个worker要加载模型），则用常驻工作池。
无论选择哪种方案，有几个原则是共通的：并发数必须依据下游承受能力设置，错误不能被静默吞掉，结果收集要考虑并发安全（用channel或互斥锁保护共享数据），长时间运行的任务务必加context超时和取消机制。把这几点做到位，你的Golang并发批量处理程序就能在高并发下既跑得快，又稳得住。