range遍历channel会阻塞直至关闭；正确做法是由sender在发送完毕后唯一关闭，否则易导致死锁或panic；for-select更适用于需超时、取消或条件退出的场景。
range channel 会阻塞直到 channel 关闭
用 range 遍历 channel 是最常见写法，但它隐含一个关键前提：只有当 channel 被 close() 后，range 才会退出。如果 sender 忘记关闭、或根本没打算关（比如持续生产日志），range 就永远卡住。
典型错误场景：
-
goroutine 发送完数据就退出，但没调用
close(ch) - 多个 sender 并发写入，但只由其中一个 close —— 可能 panic（close 已关闭的 channel）或漏数据
- sender 和 receiver 生命周期不匹配，例如 receiver 启动早于 sender，或 sender 还在运行时 receiver 已 exit
正确做法是：**明确谁负责关闭，且仅由该 goroutine 关闭一次**。通常由 sender（或其协调者）在所有发送完成之后调用 close(ch)。
for-select 模式更适合带超时或条件退出的读取
当不能依赖 close()，或需要响应外部信号（如 context cancel、超时、中断）时，for-select 是更可控的选择。
立即学习“go语言免费学习笔记（深入）”；
示例结构：
for {
select {
case v, ok := <-ch:
if !ok {
return // channel 已关闭
}
// 处理 v
case <-ctx.Done():
return // 主动退出
case <-time.After(5 * time.Second):
// 超时逻辑（可选）
}
}注意点：
v, ok := 中的ok仅表示 channel 是否已关闭，不反映是否还有数据待读（缓冲 channel 可能仍有值）- 不要在
select外层套range，否则失去控制力 - 若 channel 无缓冲且 sender 可能长时间不发数据，需搭配 default 或超时避免饿死
sync.WaitGroup + close 配合是多 sender 场景的安全解法
多个 goroutine 同时向同一 channel 写入时，不能让每个都去 close。常见错误是并发 close 导致 panic：panic: close of closed channel。
安全做法是用 sync.WaitGroup 等待所有 sender 完成，再统一 close：
var wg sync.WaitGroup ch := make(chan int, 10)// 启动多个 sender for i := 0; i < 3; i++ { wg.Add(1) go func(id int) { defer wg.Done() for j := 0; j < 5; j++ { ch <- id*10 + j } }(i) }
// 单独 goroutine 等待并关闭 go func() { wg.Wait() close(ch) }()
// receiver 正常 range for v := range ch { fmt.Println(v) }
关键约束：
- 所有 sender 必须调用
wg.Done()，包括异常退出路径（建议 defer） -
close(ch)必须且只能在wg.Wait()返回后执行 - receiver 启动时间必须晚于 close goroutine 启动（否则可能漏掉 close 通知）
channel 缓冲区大小影响遍历行为和内存占用
缓冲 channel（make(chan T, N)）会让 sender 在缓冲未满时不阻塞，但这不改变 receiver 遍历逻辑本身——range 仍等 close，select 仍靠 ok 判断是否结束。
但缓冲区大小会影响：
- sender 是否能“快速甩出”数据而不被 receiver 拖慢（适合 burst 场景）
- 内存驻留数据量：缓冲区越大，未消费数据占内存越多
- receiver 第一次
range或是否立即返回（空缓冲 channel 会阻塞）
没有银弹。小缓冲（如 1–10）适合低延迟、高响应场景；大缓冲（如 1000+）适合吞吐优先、容忍短时积压的 pipeline；零缓冲则强制同步协作，适合精确配对操作。
遍历时真正要盯住的，从来不是缓冲大小，而是谁关 channel、何时关、关几次——这个逻辑错一点，整个并发流就不可控。
