本文深入解析 go 中无缓冲通道（unbuffered channel）如何在生产者-消费者模型中实现天然的 goroutine 同步，阐明 `msgs
在你提供的代码中，msgs := make(chan int) 创建的是一个无缓冲通道（unbuffered channel）。这是理解整个行为的关键：无缓冲通道的发送操作 <- 是同步且阻塞的——它必须等待另一个 goroutine 同时执行对应的接收操作 <-msgs，二者“手拉手”完成数据传递后，发送方才能继续执行后续语句。
因此，当 produce() 执行 msgs <- i 时，并不会立即将值写入缓冲区并返回；而是暂停（goroutine 被挂起），直到 consume() 正好执行到 msg := <-msgs 并准备好接收。这正是你观察到的现象："sending" 和 "Consumer: X" 严格交替出现，且 "sent" 总是在消费者打印之后才输出。循环执行到 i = 9 后，第十次发送（msgs <- 9）依然需等待消费，而此时 consume() 尚未退出，所以 produce() 能顺利执行完全部 10 次发送，随后才打印 "Before closing channel" 并调用 close(msgs)。
但原代码中 consume() 函数存在严重缺陷：其 for { ... } 是无限循环，且未处理通道关闭信号。当 produce() 关闭 msgs 后，<-msgs 不会 panic，而是立即返回零值（0）并继续循环——这会导致消费者陷入“假消费”：不断读取到 0，且因 time.Sleep 存在，主 goroutine 已通过 <-done 退出，程序可能提前终止或产生竞态。正确做法是使用 for range msgs，它会在通道关闭且所有已发送值被接收后自动退出循环：
func consume() {
for msg := range msgs { // ✅ 自动感知 close，安全退出
time.Sleep(100 * time.Millisecond)
fmt.Println("Consumer:", msg)
}
fmt.Println("Consumer exited gracefully")
}此外，为提升健壮性，建议：
- 使用带缓冲通道（如 make(chan int, 10)）解耦生产与消费速率，避免生产者过度阻塞；
- 在 main() 中添加 time.Sleep 或 sync.WaitGroup 确保 consumer 完全退出（尤其调试时）；
- 避免全局变量 done 和 msgs，改用函数参数传递通道，增强可测试性。
总结：Go 的无缓冲通道不是“管道”，而是协程间的同步信令机制。生产者阻塞并非“halting 未知原因”，而是语言设计的主动协调——它确保了数据一定被消费（至少被接收），是构建可靠并发流程的基石。理解这一点，是写出地道 Go 并发代码的第一步。
