本文详解 go 程序中因无缓冲或小缓冲通道与 waitgroup 混用引发的典型死锁问题，并提供安全、可扩展的解决方案，包括增大缓冲区、使用 select 非阻塞发送、以及更推荐的错误聚合模式。
在您提供的代码中，死锁的根本原因并非并发逻辑错误，而是通道容量与发送行为不匹配：chErr := make(chan error, 1) 创建了一个仅能容纳 1 个元素的带缓冲通道，而 err3 和 err4 函数在 n == 3 时都会尝试向该通道发送错误。由于 wg.Wait() 在主 goroutine 中阻塞等待全部 5 个 goroutine 调用 wg.Done()，但 err4 在尝试写入已满的通道时会永久阻塞，导致 wg.Done() 永远不会执行，进而使 wg.Wait() 无法返回——形成典型的goroutine 阻塞链式死锁。
✅ 正确解法：避免通道阻塞，确保 WaitGroup 可完成
方案 1：合理扩大缓冲区（简单直接，适用于错误数量可控场景）
若最多有 N 个 goroutine 可能发送错误，将通道缓冲区设为 N 即可：
chErr := make(chan error, 5) // 容纳全部潜在错误
✅ 优点：改动最小，逻辑清晰；
⚠️ 注意：需准确预估最大并发错误数，过度扩容（如 make(chan error, 1000)）可能掩盖设计缺陷或造成内存浪费。
方案 2：非阻塞发送 + 忽略溢出错误（更健壮）
使用 select 配合 default 分支，避免 goroutine 因通道满而阻塞：
func err3(rand int, chErr chan error, wg *sync.WaitGroup) {
if rand == 3 {
select {
case chErr <- errors.New("Error 3"):
// 成功发送
default:
// 通道已满，跳过（或记录日志）
}
}
wg.Done()
}
// err4 同理修改✅ 优点：无论缓冲区大小如何，均不会阻塞；适合“只关心首个错误”或“错误降级处理”场景。
方案 3（推荐）：聚合错误，由主 goroutine 统一收集（最符合 Go 习惯）
摒弃多 goroutine 竞争写通道的设计，改用结构化错误处理：
func main() {
runtime.GOMAXPROCS(runtime.NumCPU())
var mu sync.Mutex
var errs []error // 安全收集错误
wg := sync.WaitGroup{}
n := 3
sendErr := func(e error) {
mu.Lock()
defer mu.Unlock()
errs = append(errs, e)
}
wg.Add(5)
go func() { if n == 1 { sendErr(errors.New("Error 1")) }; wg.Done() }()
go func() { if n == 2 { sendErr(errors.New("Error 2")) }; wg.Done() }()
go func() { if n == 3 { sendErr(errors.New("Error 3")) }; wg.Done() }()
go func() { if n == 3 { sendErr(errors.New("Error 4")) }; wg.Done() }() // 注意：此处 err4 条件应为 n==4？原文有逻辑歧义
go func() { if n == 4 { sendErr(errors.New("Error 5")) }; wg.Done() }()
wg.Wait()
if len(errs) > 0 {
fmt.Printf("Encountered %d errors: %+v\n", len(errs), errs)
} else {
fmt.Println("NO error, job done")
}
}✅ 优势：无通道竞争、无死锁风险、错误可完整保留、易于调试和扩展；
? 提示：若需严格保证“首个错误优先”，可用原子操作或带锁的 sync.Once 替代切片追加。
⚠️ 关键注意事项
- 永远不要在未关闭的无缓冲通道上执行阻塞发送（ch
- rand.Seed(time.Now().Unix()) 在并发中不安全且低效，应使用 rand.New(rand.NewSource(time.Now().UnixNano())) 实例化独立生成器；
- err4 的触发条件 rand == 3 与 err3 冲突，属逻辑冗余，建议按业务语义修正（如 err4 应为 n == 4）；
- close(chErr) 在 select 后调用是多余的（通道已无引用），且对已关闭通道再次 close 会 panic。
综上，死锁预防的核心原则是：确保所有 goroutine 都能无条件完成其生命周期（尤其是 wg.Done() 调用），不依赖其他 goroutine 的同步操作。优先选择方案 3 的聚合模式，它既消除了竞态根源，又提升了代码可维护性与健壮性。
