应使用带超时的select、done通道通知、生产者单方close通道，并配合for v, ok := range ch安全消费剩余数据。
channel阻塞导致goroutine泄漏怎么办
生产者或消费者没正确退出时，chan持续阻塞，对应goroutine永远卡住，内存和goroutine数只增不减。这不是“慢”，是资源持续泄露。
关键不是等channel关了再退出，而是让双方对“结束”有共识：
- 用带超时的
select包裹recv或send，避免无限等待； - 消费者监听
done通道（chan struct{}），一收到信号就立即退出循环； - 生产者完成数据发送后，必须关闭channel（
close(ch)），但仅由生产者关，消费者绝不能关； - 关闭后消费者仍要能安全读完剩余数据——用
for v, ok := 模式。
buffered channel和unbuffered channel选哪个
选错直接影响吞吐和死锁风险。unbuffered channel（make(chan int)）要求收发双方同时就绪，适合强同步场景；buffered（make(chan int, 10)）允许异步暂存，但缓冲区大小不是越大越好。
常见误判：
立即学习“go语言免费学习笔记（深入）”；
- 以为“加buffer就能防阻塞”——其实只是把阻塞延迟到buffer满时，且容易掩盖背压问题；
- 用
make(chan int, 1)模拟“单任务队列”，结果消费者卡住时，第二个生产者仍会阻塞； - 在高吞吐场景盲目设大buffer（如10000），导致内存占用突增、GC压力上升，且掩盖了消费者处理不过来的事实。
建议：先用unbuffered验证逻辑，再根据实际吞吐/延迟需求，用小buffer（如8、16、64）做平滑缓冲，配合监控channel长度（len(ch)）。
消费者怎么知道生产者彻底结束了
range遍历channel看似简洁，但只适用于“生产者明确关闭channel”且“消费者不需响应外部中断”的场景。现实里往往更复杂。
典型陷阱：
- 生产者panic中途退出，没来得及
close(ch)，消费者range ch永远卡住； - 多个生产者往同一channel写，谁关、何时关、是否都关——极易出竞态；
- 消费者需要在超时、信号中断、错误发生时主动退出，
range无法打断。
更健壮的做法是组合使用：select + ok判断 + done通道：
for {
select {
case v, ok := <-ch:
if !ok {
return // channel closed
}
process(v)
case <-done:
return // external shutdown signal
case <-time.After(30 * time.Second):
log.Println("timeout, exiting")
return
}
}为什么用channel不用mutex+slice模拟队列
表面上都能存数据，但本质不同：channel是**通信机制**，mutex+slice是**共享内存机制**。Go推荐前者，不只是因为语法简洁。
真实代价差异：
- 用mutex保护slice，消费者要轮询或sleep等待新数据，浪费CPU或增加延迟；channel天然挂起goroutine，零开销等待；
- 多个goroutine并发读写slice需自己处理边界、扩容、迭代中修改等细节，极易出bug；channel的
send/recv是原子操作，语义清晰； - channel可直接配合
context取消、超时、截止时间，mutex+slice做不到。
唯一例外是极低延迟、确定无并发竞争的内部缓存（如预分配池），但那已不属于“生产者消费者”模式范畴。
真正难的是设计好channel生命周期和退出路径——这里没有银弹，只有反复验证阻塞点和关闭时机。
