本文详解 Go 中因 break 误用导致 sync: negative WaitGroup counter panic 的根本原因，并提供基于 range 和 defer wg.Done() 的安全、简洁、符合 Go 惯用法的通道读取方案。
本文详解 go 中因 `break` 误用导致 `sync: negative waitgroup counter` panic 的根本原因，并提供基于 `range` 和 `defer wg.done()` 的安全、简洁、符合 go 惯用法的通道读取方案。
在 Go 并发编程中，使用 sync.WaitGroup 协调 goroutine 生命周期时，一个常见却隐蔽的错误是：在 select 或 for 循环内错误地调用 wg.Done() 多次，或未确保 Done() 仅执行一次。问题中的 panic 正源于此。
原始代码中，接收 goroutine 使用无限 for ; ; 循环配合 select 读取通道：
go func() {
for ; ; {
select {
case chanoutput, ok := <-somechan:
if ok {
fmt.Println(string(*chanoutput))
} else {
fmt.Println("DONE")
fmt.Println(ok)
wgread.Done() // ⚠️ 问题所在：通道关闭后，ok 变为 false，但循环未退出！
break // ❌ 仅跳出 select，而非外层 for，下一轮继续执行 → 再次调用 Done()
}
}
}
}()关键错误在于：break 语句仅终止最近的 select（或 switch/case），不会退出外层 for 循环。当通道关闭后，ok == false 分支执行 wgread.Done() 并 break，但循环立即重新开始——再次进入 select，再次读到 ok == false，再次调用 wg.Done()。由于 WaitGroup 计数器已被减至 0，第二次 Done() 就触发 negative WaitGroup counter panic。
✅ 正确做法是：让 goroutine 在通道关闭后自然退出循环，并确保 wg.Done() 仅调用一次。最简洁、最符合 Go 惯用法的方式是使用 for range：
wgread.Add(1)
go func() {
defer wgread.Done() // ✅ 延迟调用，保证仅执行一次，且无论何处 return 都生效
for chanoutput := range somechan { // ✅ range 自动检测通道关闭，循环结束即退出 goroutine
fmt.Println(string(*chanoutput))
}
fmt.Println("DONE") // 通道关闭后执行，逻辑清晰
}()
wgread.Wait()for range ch 是 Go 专为通道设计的语法糖：它会在接收到最后一个值后，自动检测通道已关闭（ok == false），并优雅终止循环，无需手动检查 ok 或管理 break 层级。配合 defer wg.Done()，可彻底避免重复 Done() 和过早 Done() 风险。
? 进阶建议：若接收逻辑简单且无需并发（即主线程等待读取完成即可），甚至可省略 goroutine 和 WaitGroup：
// 主线程直接同步读取，更简洁、无竞态风险
for chanoutput := range somechan {
fmt.Println(string(*chanoutput))
}
fmt.Println("DONE")总结：
- ❌ 避免在 for 循环内对 ok == false 手动 break 后仍继续循环；
- ✅ 优先使用 for range ch 替代手动 select + ok 检查；
- ✅ 总是用 defer wg.Done() 确保计数器准确递减；
- ✅ 若无并发需求，直接同步读取通道是最安全、最高效的选择。
