Go 语言中 channel 在关闭状态下的并发安全性

从已关闭的 channel 接收是安全的，但不检查 ok 就直接用 v := <-ch 会导致误将零值当作有效数据，必须用 v, ok := <-ch 且判断 ok 为 false 才能准确识别关闭状态。

在 Go 的并发世界里，channel 关闭是个高频踩坑点。你可能会想：通道关了还能读吗？会不会崩？答案是——读是安全的，但如果不检查 ok，直接 v := <-ch 就会源源不断地拿到零值。这不是 bug，而是 Go 刻意设计的语义：它把“是否关闭”的判断权交给你，而不是替你拍板。

接收已关闭 channel：为什么 ok 检查不能省

关闭后的 channel 不会 panic，但行为要分两阶段看：先吐完缓存里的剩饭，然后每次 <-ch 都返回零值 + false。如果你只写 v := <-ch，就等于默认吞下这个零值，而它很可能和合法业务零值（比如 0、""）混在一起，根本区分不出来。

• 有缓冲 channel：关闭后还能把缓存里的剩余值读干净，读完才开始返零值
• 无缓冲 channel：关闭后下一次读就立即返零值 + false
• 用 for v := range ch 是最省事的写法，它底层就是自动检查 ok，然后在 false 时乖乖退出
• 单次读取必须写 v, ok := <-ch，否则你永远分不清“数据本来就是零”还是“通道已经关了”

向已关闭 channel 发送：panic 不可 recover，必须从源头避免

往已关闭的 channel 里塞数据？那会直接引发 panic: send on closed channel，而且这个 panic 不能用 recover() 安全捕获——这不是技术限制，是 Go 故意的：它要把生命周期错误暴露在开发阶段，而不是藏到运行时逻辑里让你半夜排查。

• 唯一安全的关闭者是发送方，而且只能关一次；多个 goroutine 同时发，就必须协调谁来关（常用 sync.Once 或由主 sender 统一关）
• defer close(ch) 看起来简洁，但前提是那个 goroutine 确实是唯一的写入者，而且不会被重复启动
• 用 select + default 做非阻塞发送时，发送失败不等于该关 channel，别把一时的阻塞误判为“流结束”
• 多写者场景下，标准解法是把写通道设为 nil：在 select 中让那个分支永久阻塞，自然就跳过了写入

关闭时机错位：典型竞态不是“读不到”，而是“读到不该读的零值”

常见的翻车姿势是：发送端循环发完就立刻 close(ch)，接收端还在 select 里轮询——调度器可能让接收端抢在 close() 之后、select 下一轮之前执行 <-ch，结果拿到 "" 或 0，直接污染了业务统计或状态机。

• 修复核心在于把“通知结束”和“关闭 channel”两个动作拆开：先发信号（比如往 done chan struct{} 里写），接收端收到后主动退出，再关 channel
• 如果接收端用 for range，发送端关 channel 就行，但必须确保所有发送都已经完成（包括最后一个 ch <- 返回）
• 别依赖 sync.WaitGroup 的 Wait() 之后立刻 close()：WG.Done() 和 close() 之间存在竞态窗口
• 超时或上下文取消时，发送端应该提前退出并关 channel；接收端也要监听 ctx.Done() 防止卡死

真正容易被忽略的点不在语法，而在语义：channel 关闭不是“停止通信”，而是“承诺不再发新数据”。只要还有 goroutine 觉得自己还能发，或者接收方没意识到该停，这个承诺就随时可能被打破——而 Go 不会帮你兜底，它只提供清晰的规则，剩下的全靠你对数据流边界的理解。