Go语言无isClosed()函数，也无法安全跨版本检测通道关闭，唯一可靠方式是通过接收操作的返回值v, ok :=判断。
Go 语言没有 isClosed() 函数，也没有任何安全、稳定、跨版本可用的运行时检测方式。你真正能依赖的，只有接收操作本身的返回值——v, ok := 中的 <code>ok。
为什么不能用 reflect 或 runtime 字段探测 channel 是否关闭
有人试图用 reflect.ValueOf(ch).IsNil() 判断，但这会 panic：reflect: call of reflect.Value.Interface on zero Value；也有人想读 hchan.closed 这类未导出字段，但这是 runtime 包内部实现，不同 Go 版本甚至 GC 模式下结构可能变化，轻则读错，重则直接崩溃。Go 明确不承诺这些字段的稳定性，也不支持用户绕过类型系统窥探 channel 状态。
更关键的是：channel 关闭不是“可观测状态”，而是一次单向协作动作。设计上就拒绝让你“查”，只允许你“试”。
用 v, ok := 是唯一正确姿势
这个表达式不是“技巧”，是语言强制你使用的契约机制：
立即学习“go语言免费学习笔记（深入）”；
-
ok == true：成功读到一个值（可能是零值，比如0、""、nil），channel 仍开放或缓冲区还有数据 -
ok == false：channel 已关闭，且所有已发送数据（包括缓冲区）都已被读完 - 永远不要只看
v的值来判断——int类型 channel 关闭后读出来就是0，但它未必是业务上的“无效信号” - 在
select中也必须写成case v, ok := ，否则无法区分零值和关闭
for range 隐含了 ok 检查，但有隐藏前提
for v := range ch 看似简洁，其实底层等价于不断执行 v, ok := 并在 <code>ok == false 时退出循环。但它只在「下一次尝试接收」时才感知关闭——如果 channel 在循环中途被关，但缓冲区还有未读数据，它会继续读完才退出。
这意味着：
- 不能混用
for range ch和单独的操作，容易漏掉或重复处理最后几个值 - 如果你需要“立刻响应关闭”，比如清理资源或提前退出，
for range不够及时，得配合context.Context - 若发送方从不 close，
for range会永久阻塞，必须由发送方或协调 goroutine 显式调用close(ch)
真正难的不是“怎么查”，而是接受协作契约
当你发现自己反复轮询 ok、或想“监听关闭事件”，大概率说明设计偏了。Go 推荐用 context.WithCancel 替代 channel 关闭来传递终止信号：发送方调用 cancel()，接收方 select 等 。这样语义清晰、可组合、不依赖 channel 生命周期管理。
还有一点常被忽略：只读 channel（）根本不能 close，编译器直接报错。如果你在接收函数里想“关掉传进来的 channel”，说明接口契约没理清——关闭权永远属于发送方。
