从已关闭的channel接收是安全的，但不检查ok就直接用v :=
从已关闭的 channel 接收是安全的，但不检查 ok 就直接用 会持续拿到零值，这不是 bug，而是 Go 的明确设计——它把“是否关闭”的判断权交给你，而不是替你做决定。
接收已关闭 channel：为什么 ok 检查不能省
关闭后的 channel 不会 panic，但行为分两阶段：先吐完缓存数据，之后每次 都返回零值 + <code>false。如果你只写 v := ，就等于默认接受这个零值，而它可能和合法业务零值（如 <code>0、""）无法区分。
- 有缓冲
channel：关闭后还能读出剩余缓存值，读完才开始返零值 - 无缓冲
channel：关闭后下一次读就立即返零值 +false - 用
for v := range ch是最简方式，它底层就是自动检查ok并在false时退出 - 单次读取必须用
v, ok := ，否则无法区分“数据是零”还是“channel 已关”
向已关闭 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 下一轮前执行 ，结果拿到 <code>"" 或 0，污染业务统计或状态机。
- 修复核心是分离“通知结束”和“关闭 channel”两个动作：先发信号（如往
done chan struct{}写），接收端收到后主动退出，再关 channel - 若接收端用
for range，则发送端关 channel 即可，但必须确保所有发送已完成（包括最后一个ch 返回） - 不要依赖
sync.WaitGroup的Wait()后立刻close()：WG.Done() 和 close() 之间存在竞态窗口 - 超时或上下文取消时，发送端应提前退出并关 channel；接收端也需监听
ctx.Done()防止卡死
真正容易被忽略的点不在语法，而在语义：channel 关闭不是“停止通信”，而是“承诺不再发新数据”。只要还有 goroutine 认为自己能发，或者接收方没意识到该停，这个承诺就随时可能被打破——而 Go 不会帮你兜底，它只提供清晰的规则，剩下的靠你对数据流边界的准确建模。
