在 Go 中，使用一个缓冲通道配合多个读取协程时，若未正确关闭通道并处理接收终止逻辑，极易触发“all goroutines are asleep”死锁错误；关键在于确保发送方关闭通道的时机早于 wg.Wait()，且所有读者能及时感知关闭状态并主动退出。
在 go 中，使用一个缓冲通道配合多个读取协程时，若未正确关闭通道并处理接收终止逻辑，极易触发“all goroutines are asleep”死锁错误；关键在于确保发送方关闭通道的时机早于 `wg.wait()`，且所有读者能及时感知关闭状态并主动退出。
要实现一个缓冲通道（buffered channel）被多个 goroutine 安全并发读取，核心挑战在于：通道关闭时机、读者退出机制与同步等待的协调。原代码中死锁的根本原因是：wg.Wait() 在 close(cs) 之前被调用，而所有 reader 协程仍在阻塞等待从已无数据且未关闭的通道中接收值——此时 sender 已退出，通道既未关闭又无新数据，所有 reader 永久阻塞，wg.Wait() 永不返回。
✅ 正确做法：发送方负责关闭通道，并确保读者能优雅退出
- 关闭通道必须由 sender 发起，且在发送完毕后立即执行（推荐用 defer close(cs)）；
- 每个 reader 必须通过 x, ok := ；
- close(cs) 必须发生在 wg.Wait() 之前，但不能放在 main 函数末尾——因为此时 reader 可能尚未开始读取或仍在等待，导致 wg.Wait() 提前阻塞。
以下是修复后的完整示例：
package main
import (
"fmt"
"strconv"
"sync"
)
func sender(wg *sync.WaitGroup, cs chan int) {
defer wg.Done()
defer close(cs) // ✅ 关键：sender 发送完毕后立即关闭通道
for i := 0; i <h3>⚠️ 关键注意事项</h3>
- 不要在 main 中手动 close(cs)：这会导致竞态——若 close 执行过早（如在 sender 启动前），reader 可能立即收到 ok == false 而提前退出，造成逻辑遗漏；若过晚（如 wg.Wait() 之后），则必然死锁。
- 每个 reader 的 wg.Done() 必须保证执行：使用 defer wg.Done() 是最稳妥的方式，避免因 return 或 panic 导致计数遗漏。
- 缓冲通道 ≠ 多生产者/多消费者队列：本方案适用于单生产者、多消费者共享只读数据流场景；若需多个 sender，需额外加锁或改用 sync.Pool / chan struct{} 信号协调。
- 性能提示：缓冲大小应合理预估（如本例 1000 远超实际发送量 2），过大浪费内存，过小可能导致 sender 阻塞（虽本例无此问题，但通用设计需考虑）。
通过以上调整，即可安全、高效地让多个 reader 并发消费同一缓冲通道，彻底规避死锁风险。
