本文深入解析 go 中无缓冲通道（unbuffered channel）如何在生产者-消费者模型中实现天然的 goroutine 同步，阐明为何 `produce()` 会阻塞等待消费、何时关闭通道才安全，以及如何正确设计并发协作逻辑。
在 Go 的并发模型中，无缓冲通道（unbuffered channel）本质上是一个同步点——发送操作 ch 永久阻塞，直到有另一个 goroutine 正在执行对应的接收操作
你的 msgs 通道是通过 make(chan int) 创建的，属于无缓冲通道。因此，当 produce() 执行 msgs 主动等待消费者就绪并完成一次接收。观察增强版日志输出：
func produce() {
for i := 0; i < 4; i++ {
fmt.Println("sending")
msgs <- i // ⚠️ 此处阻塞，直到 consume() 执行 <-msgs
fmt.Println("sent") // 只有接收完成后才执行
}
fmt.Println("Before closing channel")
close(msgs)
done <- true
}输出清晰显示：sending → Consumer: X → sent 严格交替发生。这意味着：每次发送都与一次消费一一配对、同步完成。当 produce() 循环到 i == 9 并执行 msgs consume() 接收完 9 后，仍会立即尝试下一次接收 。此时 msgs 尚未关闭，且无新数据，于是 consume() 自身也阻塞在
- produce() 卡在 msgs
- consume() 卡在
→ 形成僵局（deadlock）前的临界状态。但注意：你的原始程序并未真正死锁，因为 produce() 最终完成了全部 10 次发送（说明 consume() 确实接收了 0–9），只是 produce() 的后续语句（close(msgs) 等）被延迟执行——这是因为 produce() 的第十次发送 msgs
✅ 正确解法是让 consume() 感知通道关闭，而非无限等待。应改用 for range 语句：
func consume() {
for msg := range msgs { // ✅ 自动在 msgs 关闭后退出循环
time.Sleep(100 * time.Millisecond)
fmt.Println("Consumer: ", msg)
}
fmt.Println("Consumer exited gracefully.")
}for range ch 是 Go 推荐的消费惯用法：它会在通道关闭且所有已发送值被接收完毕后自动退出循环，避免手动管理接收逻辑和退出条件。
⚠️ 重要注意事项：
- 关闭通道的责任归属：应由唯一生产者（或明确协调者）关闭通道，消费者绝不应关闭。否则可能触发 panic。
- 关闭时机：必须在所有生产任务完成且最后一条数据发出后关闭，如示例中 for 循环结束后。
- 避免向已关闭通道发送：close() 后再执行 ch
- 缓冲通道的区别：若声明为 make(chan int, 10)，则最多可缓存 10 个值，生产者可在无人接收时连续发送（直到缓冲满），此时同步性减弱，需额外机制协调结束。
总结：Go 的无缓冲通道不是“消息队列”，而是协程间的同步信令装置。理解 send ↔ receive 的原子配对行为，是掌握 Go 并发编程的基石。生产者-消费者模式的健壮实现，依赖于通道类型选择、关闭契约约定，以及消费者对 range 语义的正确使用。
