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