应确保生产者发完数据后显式调用close(ch)，消费者须用val, ok := <-ch检测通道关闭，避免因未关闭或未检查ok导致goroutine永久阻塞泄漏。
channel阻塞导致goroutine泄漏怎么办
生产者或消费者没按预期退出时，
会一直挂起，对应 goroutine 永远不会被回收。常见于忘记关闭 channel、或消费者没检查
就直接读取。
生产者必须在发完所有数据后调用
，不能只靠
消费者必须用
如果生产者可能 panic，用
不安全——应改用带 recover 的显式关闭逻辑
调试时可加
打点，发现数量持续上涨就说明有泄漏
如何让多个消费者公平消费一个channel
直接把同一个
传给多个 goroutine 是可行的，但 Go 运行时会随机调度，不保证轮询或负载均衡——这不是 bug，是设计使然。
若需严格轮询，得自己加锁 + 队列（比如用
包裹
），但会损失并发吞吐
更常见做法是接受“随机分发”，靠横向扩展消费者数量来摊平差异
注意：向已关闭的
写入会 panic，所以关闭前必须确保所有生产者都已退出
缓冲区大小影响明显：
是同步 channel，每次收发都阻塞；
能暂存数据，缓解生产者等待
select + timeout 处理超时消费的典型写法
消费者不能无限期卡在
配合
是标准解法。
别写
如果想重试，把
放进循环内重新生成，否则只会触发一次
注意
分支会让 select 变成非阻塞，容易忙等，一般只用于试探性读取
示例片段：
为什么用 buffered channel 有时反而更慢
缓冲区不是越大越好。过大的
会占用堆内存，且掩盖背压问题，让生产者跑得太快，最终拖垮消费者或耗尽内存。
立即学习
“
go语言免费学习笔记（深入）
”；
缓冲区大小建议设为消费者平均处理耗时 × 预期峰值 QPS，而不是拍脑袋填 1000 或 1e6
如果消费者处理逻辑含阻塞 I/O（如 HTTP 请求），缓冲区再大也救不了吞吐，此时应优先优化消费逻辑本身
用
查看当前队列长度，但注意它不是原子操作，仅适合调试或打点，不能用于控制逻辑
零缓冲 channel 更容易暴露设计缺陷——比如生产者发太快而没人接，立刻卡住，反而帮你早点发现问题
channel 的行为边界很清晰，但组合起来的调度效果不容易直觉判断。最常被忽略的是「谁负责关闭」和「关闭时机」——这两个点一旦错，整条流水线就僵在那里，连日志都不再输出。
chanokclose(ch)returnval, ok := 判断是否已关闭，不能写成 val := 硬等defer close(ch)runtime.NumGoroutine()chansync.Mutexslicechanmake(chan int, 0)make(chan int, 100) 上，尤其当生产者出错或网络延迟时。用 selecttime.Aftercase 在循环里——每次都会新建 timer，造成泄漏；应提前定义 timeout := time.After(d)timeoutdefaultselect {
case val, ok := <-ch:
if !ok { return }
handle(val)
case <-timeout:
log.Println("consumer timeout")
return
}make(chan T, N)len(ch)