go中无法用反射判断channel是否关闭，因reflect包不暴露closed标志；应使用select+default非阻塞接收探测，或改用context.context等显式信号。
Go 中无法用反射直接判断 channel 是否已关闭
Go 的 reflect 包不提供任何方法来探测 channel 的关闭状态。这不是遗漏，而是设计使然：channel 的关闭状态不属于其可反射的元信息，reflect.Value 对 channel 类型只支持 Recv、Send、Close 等操作，不暴露内部 closed 标志。
常见错误是试图用 reflect.Value.Kind() == reflect.Chan 后再查某个字段或调用某方法——这行不通，运行时会 panic 或返回无意义值。
用 select + default 非阻塞探测是否已关闭
真正可行的方式是借助 channel 的读取语义：对已关闭的 channel 执行接收操作会立即返回零值和 false；而对未关闭的非空 channel 会阻塞（除非加 default）。
实际检测逻辑必须脱离反射，在运行时用原生 channel 操作完成：
立即学习“go语言免费学习笔记（深入）”；
- 仅适用于
chan 或 <code> 类型变量，不能用于 <code>reflect.Value - 对
chan int这类双向 channel，需先转为再测（避免误触发发送） - 非阻塞探测必须带
default，否则在未关闭且为空时会死锁
示例：
func IsClosed(ch <-chan struct{}) bool {
select {
case <-ch:
return true // 已关闭（读到零值+false，但这里只关心能否读）
default:
}
return false // 未关闭（或有数据未读完，但至少没关）
}
注意：这个函数不能 100% 确认“正在关闭中”的中间态（比如 goroutine 刚执行 close(ch) 但尚未完成），但对绝大多数业务场景足够可靠。
为什么不能靠 len(ch) 或 cap(ch) 判断关闭状态
len() 返回缓冲区当前元素个数，cap() 返回缓冲区容量，二者在 channel 关闭前后都完全不变。关闭 channel 不影响其长度或容量。
常见误解是看到 len(ch) == 0 && cap(ch) == 0 就认为已关闭——错。一个刚创建、从未发送过数据的无缓冲 channel 同样满足该条件，但它显然没关。
更危险的是：对已关闭 channel 调用 len() 或 cap() 完全合法，不会 panic，所以你得不到任何错误信号来提醒自己逻辑错了。
生产环境建议：别测，改用明确的 done 信号
反复探测 channel 是否关闭，往往说明控制流设计有问题。Go 推荐的协作模式是显式传递 context.Context 或额外的 作为终止信号。
- 接收方监听
ctx.Done()比轮询 channel 状态更轻量、更可控 - 发送方 close channel 前，应确保所有相关 goroutine 已收到退出通知
- 如果必须依赖 channel 关闭语义，请让关闭方负责通知，而不是让接收方猜
真正难处理的不是“怎么测”，而是“谁该负责保证关闭时机可预期”——这个责任没法推给反射或某个工具函数。
