Go语言并发数据收集的最佳方式：两种常见实现的优劣对比

核心逻辑回顾 #

你提到的两种实现都是Go中常见的并发数据收集模式，核心差异在于共享状态的管理方式：

1. 第一种方案：使用WaitGroup同步所有并发goroutine的执行完成，通过互斥锁Mutex保护共享的字符串切片，所有goroutine直接操作这个共享切片写入数据。
   核心实现代码：

   var wg sync.WaitGroup
   var mu sync.Mutex
   res := make([]string, 0, 10)
   for i := 0; i < 10; i++ {
       wg.Add(1)
       go func() {
           defer wg.Done()
           mu.Lock()
           res = append(res, getData())
           mu.Unlock()
       }()
   }
   wg.Wait()
   

2. 第二种方案：使用WaitGroup同步所有并发goroutine的执行完成，通过带缓冲的Channel传递每个goroutine产生的数据，等所有goroutine结束后关闭Channel，由主goroutine从Channel读取数据拼接成最终切片。
   核心实现代码：

   var wg sync.WaitGroup
   ch := make(chan string, 10)
   for i := 0; i < 10; i++ {
       wg.Add(1)
       go func() {
           defer wg.Done()
           ch <- getData()
       }()
   }
   wg.Wait()
   close(ch)
   res := make([]string, 0, 10)
   for data := range ch {
       res = append(res, data)
   }
   

两种方案的优劣对比 #

方案一：WaitGroup + Mutex 共享切片写入 #

优势

• 无额外内存开销：数据直接写入最终目标切片，不存在中间拷贝过程，适合对内存效率要求极高的场景。
• 逻辑直观：对于没有接触过Channel的开发者，共享内存加锁的模式学习成本更低。

劣势

• 锁粒度失控风险高：如示例代码所示，很容易将耗时的IO调用（getData()）放入锁的临界区，导致所有并发任务被互斥锁串行化，完全丧失并发带来的性能提升；即使刻意将耗时操作移到锁外，也需要持续维护临界区范围，避免不必要的锁等待。
• 锁竞争开销明显：当并发数上升时，所有goroutine会竞争同一把全局互斥锁，性能会随着并发数提升线性下降。
• 违反Go核心并发设计原则：不要通过共享内存来通信，而要通过通信来共享内存。跨goroutine的可变状态天然存在数据竞争风险，后续迭代时如果不小心在锁外修改切片，很容易引入难以排查的panic。
• 扩展性差：如果后续需要增加错误中断、超时控制、数据过滤等逻辑，需要额外在锁内增加判断，进一步扩大锁的临界区，甚至引入死锁风险。

方案二：WaitGroup + 带缓冲Channel 中转收集 #

优势

• 无数据竞争风险：不存在跨goroutine的共享可变状态，所有对切片的修改都只在主goroutine中执行，天然不需要加锁，从根源上避免了锁相关的bug。
• 并发性能稳定：带缓冲的Channel容量提前设置为与并发数一致，所有生产端的goroutine写操作不会阻塞，不存在锁竞争开销，并发数越高时性能优势越明显。
• 职责分离清晰：生产数据的goroutine完全不关心最终数据如何存储、如何过滤，只需要把结果写入Channel即可，后续扩展逻辑（比如错误传递、超时控制、限流）只需要在收集端改动，不需要修改生产端代码。
• 鲁棒性强：代码边界清晰，没有隐式的共享状态，长期维护成本远低于锁方案，这也是Vault这类主流开源项目优先选择该方案的核心原因。

劣势

• 存在额外的内存拷贝开销：数据先从生产goroutine写入Channel缓冲区，再由主goroutine读取写入最终切片，对于单条数据量极大的场景（比如单条数据超过1MB），会有一定的内存和拷贝损耗。
• 存在边界使用风险：如果未等所有生产goroutine执行完毕就提前关闭Channel，会触发向已关闭Channel写数据的panic；不过这个问题通过WaitGroup同步结束时机的逻辑即可完全规避。

选型建议 #

• 仅在并发数极低（<5）、单条数据量极大、对内存效率有极致要求的场景，可以选择第一种Mutex方案，实现时必须注意将所有耗时操作移到锁的临界区外，严格控制锁的范围。
• 绝大多数业务开发、基础设施类项目场景，优先选择第二种Channel收集方案：
  • 提前按最大并发数设置Channel的缓冲大小，避免生产goroutine阻塞。
  • 必须等所有生产goroutine通过WaitGroup确认结束后，再关闭Channel。
  • 如果需要支持错误中断、超时控制，可以直接用errgroup.Group替代原生WaitGroup，不需要额外加锁即可在主goroutine中收集错误信息。

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