正确关闭channel需等待所有生产者退出，否则向已关闭channel发送数据会panic；多channel接收应结合select与done信号避免阻塞。
Go 语言中用 channel 实现生产者-消费者模型，核心不是“能不能做”，而是“怎么避免死锁、数据丢失和 goroutine 泄漏”——这三点踩中任意一个，程序就可能静默失败或 panic。
为什么 close() channel 前必须确保所有生产者已退出
消费者通过 range 遍历 channel 时，依赖 channel 被关闭来退出循环。但如果生产者还在往已关闭的 channel 发送数据，会直接 panic：panic: send on closed channel。
- 正确做法：用
sync.WaitGroup等待所有生产者 goroutine 完成后再close(ch) - 不要在生产者内部调用
close()，除非它是唯一生产者且逻辑可控 - 若使用带缓冲的 channel（如
ch := make(chan int, 100)），关闭时机仍需同步，否则消费者可能提前退出，漏掉未被读取的数据
消费者如何安全处理多个 channel 的同时接收（select + done 信号）
真实场景中，消费者常需响应退出信号（比如收到 os.Interrupt），不能卡死在 range ch 或单个 上。
- 用
select配合donechannel 是标准解法，例如：
for {
select {
case item, ok := <-ch:
if !ok {
return // channel 已关闭
}
process(item)
case <-done:
return // 收到退出信号
}
}
- 注意：
donechannel 应是chan struct{}类型，发送struct{}{}即可，零内存开销 - 如果消费者有多个输入 channel（如日志 + 配置变更），每个
case都要检查ok，避免因某个 channel 关闭导致整个select永久阻塞在其它分支
缓冲 channel 和无缓冲 channel 对吞吐与背压的影响
选哪种不是看“习惯”，而是看你要不要控制生产速度：
立即学习“go语言免费学习笔记（深入）”；
- 无缓冲 channel（
make(chan int)）：每次send必须有对应recv同时就绪，天然实现强背压——生产者会阻塞，直到消费者腾出空档 - 缓冲 channel（
make(chan int, N)）：缓冲区满之前生产者不会阻塞，适合应对瞬时高峰；但缓冲区大小设太小没意义，设太大等于放弃背压，还可能掩盖消费者性能瓶颈 - 典型误用：用大缓冲 channel 替代限流，结果内存暴涨、延迟不可控；应配合
time.After或令牌桶等显式限流手段
真正难的不是写通逻辑，而是当并发数升到几百、channel 在多层 goroutine 间传递、中间夹着超时和重试时，还能准确判断哪个 goroutine 该关、哪个 channel 该关、哪个 select 分支该加 default —— 这些细节不靠调试，靠一开始就把退出路径画清楚。
