channel关闭后，v, ok := <-ch 中ok为false，v为零值。
channel 关闭后 v, ok := <-ch 中的 <code>ok 到底表示什么</H3>
<p><code>ok 不是“channel 是否已关闭”，而是“这次读取是否成功拿到了一个有效值”。它只和缓冲区当前是否有数据有关，和 close() 调用本身没有直接对应关系。</p>
<p>常见错误是认为 <code>ok == false 就等于“刚被 close()”，从而在逻辑里做状态同步或日志打点。实际上：</p>
<ul>
<li>如果 channel 关闭前还有 3 个 int 值在缓冲区里，<code>ok 会连续为 <code>true 三次，每次返回对应数值</li>
<li>第三次读完后缓冲区才空，第四次读才返回 <code>0, false
0, false
也就是说：
ok 反映的是“这次读有没有拿到缓存里的东西”，不是“channel 现在关没关”。关了但还有货，<code>ok 就还是 true。</p>
<H3>为什么不能用 <code>v == 0 或 <code>v == "" 当退出条件</H3>
<p>因为所有类型都有零值，而这些零值本身就是合法业务数据。比如你往 <code>chan int 发送了 <code>0，接收端用 <code>if v == 0 { break } 就会误判为 channel 已关，提前丢弃后续数据。</p><p><span>立即学习</span>“<a href="https://pan.quark.cn/s/00968c3c2c15" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">go语言免费学习笔记（深入）</a>”；</p>
<p>更隐蔽的问题出现在指针或结构体 channel 上：</p>
<ul>
<li><code>chan *string 关闭后读到 <code>nil，但业务中本来就会发 <code>nil
chan struct{} 关闭后读到 <code>struct{}{}（也就是零值），但这个值和正常发送的完全一样，<code>ok 才是唯一区分依据只要类型有可区分的零值，单靠 v 就无法判断是数据还是关闭占位符——这是 Go 的设计选择，不是 bug。
for range ch 和手写 for { v :=
for range ch 是安全的，因为它内部自动做了 <code>v, ok 检查，并在 <code>ok == false 时自然退出循环。但手写循环不带 <code>ok 判断，就会陷入无限读零值陷阱。
典型反模式：
for {
v := <-ch // ❌ 永远不会停，v 一直是 0/""/nil
process(v)
}
正确写法只有两种：
- 用
for v := range ch（推荐，简洁且语义清晰） - 手动检查
ok：for { v, ok :=
注意：for range 对 nil channel 会永久阻塞，所以如果 ch 可能为 nil，得先判空：<code>if ch == nil { return }
select 中读已关闭 channel 容易卡死的边界情况
当 select 里只有一个 case 是已关闭的 channel，且没写 <code>default 或超时，就会变成“每次都成功读到零值 + ok=false”，然后继续下一轮 select——形成 CPU 空转死循环。
例如：
for {
select {
case v, ok := <-ch:
if !ok {
return // ✅ 必须显式退出
}
process(v)
}
}
漏掉 if !ok { return }，或者把 <code>ch 设为 <code>nil 后没加 <code>default，都可能让 goroutine 卡住或 panic。特别要注意的是，<code>ch = nil 后再进 select，该 case 会立即忽略（不是阻塞），但如果其他 case 都不可达，整个 select 就会阻塞——这和关闭 channel 的行为完全不同。
真正容易被忽略的是：关闭操作和接收方感知之间存在非原子窗口。哪怕 sender 写完最后一项立刻 close(ch)，receiver 仍可能在 <code>close() 执行前就已从缓冲区读完全部数据并退出。协作必须靠明确信号顺序，而不是依赖“关了就立刻没数据”这种直觉。
