本文详解 go 程序中因 channel 使用不当导致的“all goroutines are asleep - deadlock”错误，重点剖析缓冲通道误用、waitgroup 传参陷阱及关闭时机错误三大根源，并提供符合 go 并发哲学的安全实践方案。
本文详解 go 程序中因 channel 使用不当导致的“all goroutines are asleep - deadlock”错误，重点剖析缓冲通道误用、waitgroup 传参陷阱及关闭时机错误三大根源，并提供符合 go 并发哲学的安全实践方案。
在 Go 并发编程中，“fatal error: all goroutines are asleep - deadlock!” 是一个典型且易被忽视的运行时错误。它并非源于语法问题，而是逻辑级死锁：所有 goroutine 同时阻塞等待彼此，无人能继续推进。
以原始代码为例，问题根源有三：
sync.WaitGroup被值传递doSomething(c, wg)中wg是按值传入的，wg.Done()操作仅作用于副本，主 goroutine 中的wg.Wait()永远不会返回 —— 这是死锁的直接原因。close(c)执行过早且位置错误wg.Wait()后才调用close(c)，但此时所有写 goroutine 已退出，for v := range c才开始读取。更严重的是：close(c)发生在range循环之前，看似合理，实则掩盖了根本问题 —— 若写操作未完成就关闭，会 panic；若range在写 goroutine 运行前启动，则可能漏读（虽本例中因wg.Wait()强制同步而暂不暴露）。过度依赖缓冲区规避阻塞 ≠ 正确设计
将make(chan int, 2)改为make(chan int, 3)可“临时绕过”死锁，但这只是掩盖问题：缓冲大小与 goroutine 数量强耦合，违反可维护性原则，且丧失 channel 流式处理的核心优势。
✅ 正确解法遵循 Go 并发最佳实践：
-
sync.WaitGroup仅在声明作用域内使用（避免传参）； -
关闭 channel 的责任应由“最后写入者”承担，通常通过独立 goroutine 监听
WaitGroup完成后执行close()； - 使用无缓冲 channel 或合理缓冲，但不依赖其“容错”，让阻塞成为设计信号而非隐患；
-
range循环应尽早启动，实现生产者-消费者流水线并行。
以下是重构后的健壮实现：
package main
import (
"fmt"
"sync"
)
func main() {
c := make(chan int) // 无缓冲 channel，显式表达同步语义
var wg sync.WaitGroup
wg.Add(3)
// 启动 3 个写 goroutine
go func() { doSomething(c); wg.Done() }()
go func() { doSomething(c); wg.Done() }()
go func() { doSomething(c); wg.Done() }()
// 单独 goroutine 等待全部写入完成，并安全关闭 channel
go func() {
wg.Wait()
close(c) // 关闭时机精准：所有写操作结束后
}()
// 立即开始消费，无需等待全部写入完成（流式处理）
for v := range c {
fmt.Print(v) // 输出：111（顺序不定，但总数确定）
}
}
func doSomething(c chan<p>? <strong>关键要点总结</strong>：</p>
- ✅
WaitGroup不作为参数传递，消除副本陷阱； - ✅
close(c)由专属 goroutine 执行，确保“写完即关”，避免竞态； - ✅
range c在go启动后立即运行，天然支持并发流水线； - ✅ 无缓冲 channel 强化了“同步协作”语义，使代码意图更清晰；
- ⚠️ 切勿在
main函数中close(c)后再range——range本身会在 channel 关闭后自动退出，重复关闭会 panic。
该模式不仅消除了死锁，更体现了 Go “通过通信共享内存”的设计哲学：channel 是协程间可靠的数据信道，其生命周期管理必须严格遵循“写端关闭、读端感知”的契约。
