for range 读取 channel 易卡死，因 range 仅在 channel 关闭后结束；多生产者需用 WaitGroup 同步关闭，接收方应配合 select+default 防阻塞。
为什么直接用 for range 读取 channel 容易卡死
当多个 goroutine 同时向一个无缓冲 channel 写入，而只有一个接收方用 for range 消费时，一旦写入方提前退出（比如任务生成完毕但未显式关闭 channel），接收方会永远阻塞在 range 上——因为 range 只在 channel 关闭后才结束。这不是并发问题，是 channel 生命周期管理疏忽。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 任务生产者必须在所有任务发送完成后调用
close(ch)，不能依赖 goroutine 自行退出 - 若生产者有多个，需用
sync.WaitGroup确保全部完成后再 close，否则可能 panic：「close of closed channel」 - 接收方不要假设 channel 一定会被关闭；可在 select 中加超时或用带默认分支的循环做兜底
select + default 是防止 goroutine 积压的关键
任务分发场景中，worker 常常需要“非阻塞尝试取任务”。如果只用 <-ch，空闲 worker 会挂起，无法及时响应新任务或退出信号；若用纯轮询又浪费 CPU。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
select { case task := <-taskCh: ... default: ... }实现忙闲自适应 - 在
default分支里可做健康检查、上报指标、或 sleep 微秒级避免空转 - 若需优雅退出，把退出信号也放进 select 的 case 中，比如
case
如何避免 worker 数量与 channel 缓冲区大小互相绑架
常见误区是认为「开了 10 个 worker 就该配 buffer=10 的 channel」。实际上，buffer 大小影响的是背压传导速度和内存占用，和 worker 并发数没有数学绑定关系。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 无缓冲 channel（
make(chan Task)）适合强实时、低延迟任务，但要求 producer 和 consumer 节奏匹配，否则易阻塞 producer - 缓冲 channel（
make(chan Task, 100)）能解耦生产/消费速率，但 buffer 过大会掩盖下游处理瓶颈，且 OOM 风险随 buffer 增大线性上升 - 更稳妥的做法是 buffer 设为预估峰值并发量的 2–3 倍，并配合 metrics 监控
len(ch)和cap(ch)比值
任务分发时要不要传指针？struct 大小决定性能拐点
channel 传递数据本质是拷贝。如果传的是大 struct（比如含 []byte 或嵌套 map），每次发送都会触发内存分配和复制，GC 压力陡增；传指针虽快，但要小心 data race 和生命周期管理。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 小于 64 字节的
struct（如含 2–3 个 int/string）直接传值更高效，现代 Go 编译器能优化掉部分拷贝 - 含 slice/map/chan/interface{} 的类型，必须传指针，否则副本会共享底层数据引发竞争
- 若任务结构体中只有少量字段会被 worker 修改，可拆出只读字段传值、可变字段用原子操作或单独 channel 更新
