Golang通道遍历、关闭检测与死锁技巧

for range 读取 channel 时卡住不退出，是因为它在 channel 关闭前会持续阻塞等待新值；若 sender 未关闭或关闭时机不当，循环将永久阻塞。

for range 读取 chan 时为什么卡住不退出

因为 for range 在 channel 关闭前会一直阻塞等待新值，如果 sender 忘记关闭 channel，或关闭时机不对，循环就永远卡在 <-ch 上。这不是 bug，是设计使然：range 把 channel 当作“有限序列”来遍历，依赖 close 作为终止信号。

常见错误场景：

• sender 启动 goroutine 异步发数据但没等它结束就关闭 channel
• 多个 sender 中有一个 panic 未关闭 channel
• channel 被重复 close（panic: close of closed channel）

正确做法是确保所有 sender 完成后，由**唯一可信的协程**调用 close(ch)。推荐用 sync.WaitGroup 配合 defer close()，例如：

var wg sync.WaitGroup
ch := make(chan int, 10)
wg.Add(1)
go func() {
    defer wg.Done()
    defer close(ch) // 确保只关一次，且在发送完后
    for i := 0; i < 5; i++ {
        ch <- i
    }
}()
for v := range ch {
    fmt.Println(v)
}
wg.Wait()

想非阻塞检测 channel 是否已关闭，不能只靠 for range

for range 本身不提供“是否已关”的实时判断能力——它只在下一次接收时发现关闭并自动退出。若需在循环中主动感知关闭状态（比如做清理、切换逻辑），得用 select + ok 模式。

示例：每轮检查 channel 是否关闭，同时支持超时退出

for {
    select {
    case v, ok := <-ch:
        if !ok {
            fmt.Println("channel closed")
            return
        }
        fmt.Println("got:", v)
    case <-time.After(1 * time.Second):
        fmt.Println("timeout, exiting")
        return
    }
}

注意：ok == false 仅表示 channel 已关闭且无剩余数据；如果 channel 是带缓冲的，ok 仍为 true 直到缓冲区清空。

range chan 导致死锁的典型组合

最常踩的坑是：goroutine 启动后向 channel 发送，主 goroutine 用 for range 读，但双方都没做同步控制——一旦 sender 发送速度慢于 reader 消费速度，或 reader 先启动而 sender 迟迟未启，就可能因 channel 缓冲耗尽+无关闭信号而双双挂起。

死锁三要素（满足其二即高危）：

• channel 无缓冲，且 sender 和 receiver 不在同 goroutine
• receiver 用 for range，但 sender 没有明确 close 逻辑
• sender 和 receiver 互相等待对方先动作（如 sender 等 receiver 拿走一个值才发下一个）

避免方式：

• 始终为 channel 设置合理缓冲（make(chan T, N)），尤其当 sender/receiver 速率不可控时
• 绝不让 sender 和 receiver 在同一个 goroutine 里顺序执行（除非是带缓冲且确定不会满）
• 用 context.Context 控制生命周期，配合 select 实现可取消的 range 模拟

替代 for range 的更可控遍历方式

当需要中断、限流、错误处理或混合多个 channel 时，for range 太“黑盒”。直接用 select + 循环更灵活。

例如：从多个 channel 读，任一关闭即退出

for {
    select {
    case v1, ok1 := <-ch1:
        if !ok1 {
            return
        }
        handle(v1)
    case v2, ok2 := <-ch2:
        if !ok2 {
            return
        }
        handle(v2)
    }
}

再如：带重试的单 channel 读取（避免因临时阻塞误判关闭）

for {
    select {
    case v, ok := <-ch:
        if !ok {
            return
        }
        process(v)
    default:
        time.Sleep(10 * time.Millisecond) // 避免忙等
        continue
    }
}

真正难的不是语法，而是谁关、何时关、关几次——这些必须在设计阶段就约定清楚，写进接口文档或注释里，否则 runtime 才会给你报错。