Golang任务分发与结果汇总实现方法

本文深入剖析了 Go 语言中 Fan-out Fan-in 模式在高并发任务分发与结果汇总场景下的正确实现要点：强调可控分发、隔离执行与确定汇总，而非简单启动大量 goroutine；指出必须结合 sync.WaitGroup 显式同步任务生命周期、为 result channel 设置合理缓冲、由主 goroutine 安全关闭通道，并在每个 worker 中集成 context 控制超时与取消、defer-recover 防止 panic 扩散；同时警示常见陷阱——如 channel 类型混用、提前关闭导致 panic、共享状态未加锁、错误处理吞掉上下文取消原因等，并对比 errgroup.Group 的便利性与隐藏风险，最终落脚于工程鲁棒性——当并发量激增、超时收紧、错误率上升时，唯有对 channel 行为、context 传播、错误归因和资源回收的精细把控，才能让系统真正稳定可靠。

用 sync.WaitGroup + channel 控制并发分发与结果收集

Fan-out Fan-in 的核心不是“起一堆 go”，而是可控的分发、隔离的执行、确定的汇总。直接用 for range 启协程再塞进同一个 chan，很容易漏收、死锁或 panic。

• 必须用 sync.WaitGroup 显式标记所有子任务完成，不能依赖 channel 关闭时机来判断“是否收完”
• 结果 channel 建议设缓冲（如 make(chan Result, len(tasks))），避免某个慢协程阻塞其他协程写入
• 每个协程内部要 recover，否则一个 panic 会 kill 整个程序——defer func(){if r := recover(); r != nil { /* log */ }}()
• 不要在协程里直接操作共享 map/slice，除非加锁；更推荐每个协程返回结构体，由主 goroutine 统一合并

select 超时控制下如何安全关闭 worker 协程

实际场景中任务可能卡住（比如 HTTP 请求没设 timeout、数据库查询 hang 住），不能让 Fan-in 死等。靠 context.Context 传取消信号是唯一靠谱方式。

• worker 协程启动时接收 ctx context.Context，所有阻塞调用（http.Client.Do、time.Sleep、chan recv）都要配合 ctx.Done() 使用
• 不要用 close(resultChan) 来表示结束——多个协程 close 同一个 channel 会 panic；应该让主 goroutine 在 WaitGroup.Wait() 后手动 close
• 如果用了 select 等待 ctx.Done()，记得检查 err == context.Canceled || err == context.DeadlineExceeded，别把错误吞掉就返回空结果

为什么不用 errgroup.Group？它和手写 WaitGroup+channel 有啥区别

errgroup.Group 是标准库 golang.org/x/sync/errgroup 提供的封装，它确实省了 WaitGroup 和错误聚合逻辑，但掩盖了几个关键细节：

• 它默认不支持结果 channel，你仍得自己建 chan Result 并确保并发写安全
• 它的 Go 方法不接受返回值，所有结果必须通过闭包变量或额外 channel 中转，容易引发变量复用 bug
• 一旦某个子任务 return 非 nil error，Wait() 会立刻返回，但其余还在跑的协程不会被自动 cancel——除非你显式传入带 cancel 的 ctx
• 在高并发（比如 1000+ worker）下，errgroup 的锁开销略高于裸 WaitGroup，不过通常可忽略

结果汇总时常见的类型错位和 channel 关闭时机问题

最常踩的坑不是逻辑，而是 channel 类型声明和关闭顺序不对。比如定义 results := make(chan *Result)，却往里 send Result{} 值类型，编译直接报错；或者主 goroutine 在 WaitGroup.Wait() 前就 close 了 channel，导致部分协程 write panic。

• 务必统一结果类型：要么全指针 *Result，要么全值类型 Result，别混用
• 关闭 channel 的唯一安全位置是：所有 worker 启动完毕 + wg.Wait() 返回之后
• 如果需要按顺序输出结果（非完成顺序），别依赖 channel 接收顺序——改用索引数组 + sync.Once 或带序号的 struct
• 注意 range 读 channel 会阻塞到 close，所以一定要确保 close 发生在所有发送结束后，且没有 goroutine 还在往里 send

事情说清了就结束。真正难的不是写出能跑的 Fan-out Fan-in，而是当 worker 数量从 10 涨到 500、超时从 1s 缩到 200ms、错误率突然升到 15% 时，你的 channel 缓冲大小、context 取消路径、recover 日志粒度，还是否经得起压。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Golang任务分发与结果汇总实现方法》文章吧，也可关注golang学习网公众号了解相关技术文章。