本文深入解析 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
