本文详解 go 程序中因 channel 使用不当导致“all goroutines are asleep - deadlock”错误的根本原因，并提供符合 go 并发哲学的安全、可扩展解决方案。
本文详解 go 程序中因 channel 使用不当导致“all goroutines are asleep - deadlock”错误的根本原因，并提供符合 go 并发哲学的安全、可扩展解决方案。
你遇到的 fatal error: all goroutines are asleep - deadlock! 并非偶然，而是 Go 并发模型中一个典型的设计陷阱：channel 的生命周期管理与 goroutine 协作逻辑不匹配。
在原始代码中，存在三个关键错误：
sync.WaitGroup值传递导致计数失效doSomething(c, wg)将wg以值方式传入，意味着每个 goroutine 操作的是wg的副本，wg.Done()不会影响主 goroutine 中的原始WaitGroup，因此wg.Wait()永远不会返回，主 goroutine 阻塞。close(c)被延迟到wg.Wait()之后执行，但此时所有写 goroutine 已退出，而主 goroutine 又在for v := range c中等待从 channel 读取 —— 但无人再向 channel 发送数据，且 channel 尚未关闭，导致range永久阻塞。缓冲区大小（
make(chan int, 2)）被误当作“解药”：即使将缓冲区设为 3，也仅是掩盖问题——它依赖硬编码容量匹配 goroutine 数量，丧失可维护性与可扩展性（如新增 goroutine 就必须同步调大缓冲区），违背 Go “用通信共享内存”的设计初衷。
✅ 正确做法是：分离“生产”与“消费”生命周期，让 channel 关闭时机由生产者集体完成信号驱动，而非由消费者（主 goroutine）串行控制。
以下为推荐实现（已修复所有问题）：
package main
import "fmt"
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) // 关闭后，range 自动退出
}()
// 主 goroutine 立即开始消费，无需等待生产者完成
for v := range c {
fmt.Print(v) // 输出：111（顺序不定）
}
}
func doSomething(c chan<p>? <strong>关键设计要点说明：</strong> </p>
- ✅
WaitGroup保留在main作用域内，通过闭包捕获，避免值传递错误； - ✅
close(c)在独立 goroutine 中执行，确保range c不会因 channel 未关闭而永久挂起； - ✅
range c可立即启动消费，实现真正的流式处理（streaming），提升响应性与资源利用率； - ✅ 无缓冲 channel 强制生产/消费同步点显式化，降低隐式依赖风险；
- ✅ 所有 goroutine 协同受控退出，无竞态、无泄漏、无死锁。
⚠️ 注意事项：
- 切勿在多个 goroutine 中重复调用
close()，会导致 panic；应确保仅由单一确定方（通常是协调者 goroutine）执行； - 若生产者可能 panic，建议配合
recover或使用errgroup等更健壮的并发控制库； - 实际项目中，推荐使用
context.Context控制超时与取消，增强健壮性。
掌握 channel 的关闭契约（谁关、何时关、关几次）和 WaitGroup 的作用域约束，是写出可靠 Go 并发代码的基石。
