本文揭示go程序中因waitgroup.add()调用位置不当引发的竞态隐患：若在goroutine启动后才调用add(1)，主协程可能提前执行wait()，导致子协程被跳过——缓冲区大小变化仅是暴露该bug的触发条件，而非根本原因。
本文揭示go程序中因waitgroup.add()调用位置不当引发的竞态隐患：若在goroutine启动后才调用add(1)，主协程可能提前执行wait()，导致子协程被跳过——缓冲区大小变化仅是暴露该bug的触发条件，而非根本原因。
在Go并发编程中，sync.WaitGroup 是协调多个goroutine生命周期的核心工具，但其正确使用高度依赖调用时序。上述代码看似逻辑清晰：启动7个读取goroutine、向带缓冲通道写入100个整数、关闭输入通道、等待所有读取完成、再关闭输出通道并等待打印结束。然而，当缓冲区容量 ≥ 100（如 make(chan int, 100)）时，程序静默退出、无任何输出——这并非通道缓冲机制失效，而是典型的 WaitGroup 使用时序错误。
根本原因：Add() 必须在 goroutine 启动前调用
wg1.Add(1) 被错误地放在 readInt 函数内部、for range 循环开始之后：
func readInt(in chan int, out chan string, id int) {
wg1.Add(1) // ❌ 危险！此处执行已晚于 goroutine 启动
for n := range in {
out <- fmt.Sprintf("goroutine:%d was sent %d", id, n)
}
wg1.Done()
}Go 的 goroutine 启动是异步且不可预测的。主协程执行 go readInt(...) 后立即继续运行，快速完成 for i:=1; i<=100; i++ { share <- i } 和 close(share)，随后调用 wg1.Wait()。此时，若部分 readInt goroutine 尚未执行到 wg1.Add(1)（甚至尚未开始执行），WaitGroup 的计数器仍为 0，wg1.Wait() 会立即返回，导致后续 close(out) 和 wg2.Wait() 被执行，而所有 readInt goroutine 实际上还未开始消费通道——它们在 for n := range in 处阻塞，因为 in 已关闭但无人通知其“该结束了”，更关键的是，wg1.Done() 永远不会被调用，形成逻辑死锁（虽不panic，但行为不可控）。
而小缓冲区（如 cap=10）“看似工作正常”，是因为发送操作 share <- i 在缓冲满时会阻塞主协程，客观上为 readInt goroutine 争取了执行时间，使其大概率在主协程到达 wg1.Wait() 前已完成 wg1.Add(1)。但这属于侥幸的竞态行为，绝非可靠逻辑。
立即学习“go语言免费学习笔记（深入）”；
正确做法：Add() 必须在 go 语句之前
应将 wg1.Add(1) 移至主协程中 go readInt(...) 调用之前，确保计数器在goroutine启动前已准确反映待等待数量：
func main() {
share := make(chan int, 100) // 缓冲区大小 now irrelevant to correctness
out := make(chan string)
go printChan(out)
// ✅ Correct: Add before launching goroutines
wg1.Add(7)
for j := 1; j <= 7; j++ {
go readInt(share, out, j)
}
for i := 1; i <= 100; i++ {
share <- i
}
close(share)
wg1.Wait() // Now safely waits for all 7 goroutines to finish
close(out)
wg2.Wait()
}
func readInt(in chan int, out chan string, id int) {
// ❌ Remove wg1.Add(1) from here
for n := range in {
out <- fmt.Sprintf("goroutine:%d was sent %d", id, n)
}
wg1.Done() // Only Done() remains
}同理，printChan 的 wg2.Add(1) 也需前置（已在 go printChan(out) 之前）：
wg2.Add(1) go printChan(out)
关键注意事项与最佳实践
- 严格遵循“Add-before-go”原则：所有 wg.Add(n) 必须在对应 go 语句执行前完成，这是 WaitGroup 正确性的基石。
- 避免在 goroutine 内部 Add：除非你明确控制该 goroutine 的启动顺序（如通过 channel 同步），否则极易引入竞态。
- 缓冲区大小 ≠ 并发控制手段：通道缓冲区仅影响发送/接收的阻塞行为，不改变 goroutine 调度或 WaitGroup 语义。依赖缓冲区大小来“修复”同步问题，是掩盖设计缺陷。
- 启用竞态检测器：使用 go run -race main.go 可捕获此类数据竞争，强烈建议在开发和CI中启用。
修正后的代码无论通道缓冲区设为1、10、100或1000，均能稳定输出全部100条日志，并正常退出。这印证了：并发程序的可靠性，源于对同步原语时序的精确掌控，而非对调度细节的偶然依赖。
