go 不提供 isclosed() 函数，因关闭不可观测；应始终用 v, ok :=
Go 里没有直接判断 channel 是否关闭的内置函数
Go 语言设计上刻意不提供 isClosed() 这类函数，因为“是否关闭”本身不是 channel 的可观测状态——关闭是单向操作，且关闭后读操作仍可能成功（直到缓冲耗尽或无数据可读）。你真正能做的，只有尝试读取并观察结果。
用 + <code>ok 二值接收判断“是否还能读到有效值”
这是最常用、也最符合 Go 惯用法的方式。它不告诉你 channel “是否被关”，而是告诉你“这次读会不会阻塞/是否还有新数据可读”。
常见错误现象：
- 直接对已关闭 channel 写入 panic：send on closed channel
- 误以为 ch == nil 表示关闭（实际 nil channel 读写都永久阻塞）
- 在 select 中只写 case v := 而不加 <code>ok，导致无法区分零值和关闭信号
实操建议：
- 永远用
v, ok := 形式接收，<code>ok == false表示 channel 已关闭且缓冲为空 - 不要在循环外单独“检测关闭”，而应在每次读逻辑中自然处理
ok - 若需区分“暂时没数据”和“彻底关了”，必须配合超时或 context，仅靠
ok不够
反射无法安全获取 channel 关闭状态
有人尝试用 reflect.ValueOf(ch).IsNil() 或读取内部字段（如 recvq、closed），但这属于未导出实现细节，在不同 Go 版本间极易失效，且违反内存安全模型。
立即学习“go语言免费学习笔记（深入）”；
性能 / 兼容性影响：
-
reflect操作 channel 值本身会 panic：reflect: call of reflect.Value.Interface on zero Value（channel 是引用类型，但reflect.ValueOf对未初始化 channel 返回零值） - 即使绕过 panic，读取 runtime 包中的 struct 字段（如
hchan.closed）会导致程序在 go tip 或某些 GC 模式下崩溃 - Go 官方明确将 channel 内部结构列为“不稳定 API”，不承诺兼容
需要“主动感知关闭”的场景，应该用 sync.Once 或 context.Context 配合
比如启动 goroutine 监听 channel 并在关闭后触发清理，这时靠反复轮询 ok 效率低，也不可靠。
实操建议：
- 发送方在 close(ch) 前，先调用
once.Do(func(){ close(done) })，监听方等 - 更通用的做法：用
context.WithCancel，发送方 cancel()，监听方 select 等 - 不要试图让接收方“发现关闭”，而是让关闭动作变成一个显式、可等待的信号
真正难的不是“怎么查”，而是接受 Go 的设计哲学：channel 关闭是协作契约的一部分，不是需要监控的状态。一旦你发现自己在反复检查“它关了吗”，大概率是控制流设计该调整了。
