range 遍历 channel 会阻塞直至 channel 关闭；未关闭即 range 必死锁；多 sender 时须用 sync.WaitGroup 确保全部写完再 close，否则可能 panic。
range 读取 channel 会阻塞直到关闭
Go 中 range 遍历 channel 的本质是持续调用 recv，它不会自动退出，也不会因 sender 暂停而结束——只有 channel 被 close() 后，range 才会自然退出。没关 channel 就用 range，程序必卡死。
常见错误现象：fatal error: all goroutines are asleep - deadlock
- sender 是 goroutine，但忘记调用
close(ch) - sender 已退出，但 channel 未关（Go 不会自动关）
- 多个 sender，只关了一部分，或关早了（有 goroutine 还在往里写）
多 sender 场景下必须用 sync.WaitGroup + close 控制
多个 goroutine 往同一个 channel 写数据时，不能靠任意一个 sender 关 channel，否则可能 panic：向已关闭的 channel 发送数据会触发 panic: send on closed channel。
正确做法是等所有 sender 完成后再统一关 channel：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
var wg sync.WaitGroup
ch := make(chan int, 10)
wg.Add(2)
go func() { defer wg.Done(); for i := 0; i < 3; i++ { ch <- i } }()
go func() { defer wg.Done(); for i := 10; i < 13; i++ { ch <- i } }()
go func() { wg.Wait(); close(ch) }()
<p>for v := range ch { // 此处安全
fmt.Println(v)
}-
sync.WaitGroup记录活跃 sender 数量，不是看 goroutine 是否启动 -
close(ch)必须且只能由一个 goroutine 执行，且要在所有send完成后 - 不要在 sender 里直接
close(ch)，除非你能 100% 确保它是最后一个
range channel 无法感知“暂时无数据”，不适合做轮询或超时控制
range 是纯消费模型，没有“看看有没有、没有就走”的能力。想实现带超时的读取，不能靠 range，得用 select + case 。
使用场景举例：后台任务监听命令 channel，但也要定期检查健康状态或响应中断信号。
- 错误写法：
for v := range ch { ... }—— 完全阻塞，无法插入心跳或 ctx.Done() 判断 - 正确写法：用
select分离数据接收和控制逻辑 - 注意
default分支会让循环变成忙等，加time.Sleep或改用定时器更稳妥
示例片段：
for {
select {
case v, ok := <-ch:
if !ok { return }
handle(v)
case <-time.After(5 * time.Second):
pingHealth()
case <-ctx.Done():
return
}
}buffered channel 和 range 的配合容易误判“已读完”
带缓冲的 channel 可能看起来“还有数据”，但 range 实际上只关心是否关闭。如果 sender 写完就关 channel，哪怕缓冲区还没被消费者全部取完，range 仍会完整遍历缓冲内容；但如果 sender 没关 channel，哪怕缓冲区空了，range 也会一直等下去。
- 缓冲大小不影响
range行为逻辑，只影响阻塞时机和内存占用 - 别以为
len(ch) == 0就代表 channel “空了可退出”——len返回当前缓冲长度，不是 channel 状态指示器 - 判断 channel 是否该退出，唯一可靠依据是
ok值（来自v, ok := ）或显式关闭信号
真正容易被忽略的点：channel 关闭后，还能安全读取缓冲中剩余数据；但一旦开始读，就不能再假设“读到零值就代表结束了”——因为零值可能是业务合法数据（比如 int 的 0、string 的 ""），必须依赖 ok 判断通道是否真的关了。
