Go语言中无法原子检测channel关闭状态，只能通过接收操作v, ok :=
channel 关闭状态无法“原子检测”，只能“原子接收”
Go 语言没有提供任何安全、稳定、跨版本可用的「只读不消费」式检测方式。所谓“原子检测”本身是个误导性说法——close() 是原子操作，但「判断是否已关」这件事，语言层面只允许你通过一次接收动作来完成，且该动作必然消耗（或确认消耗）一个值。
常见错误包括：reflect.ValueOf(ch).IsNil() 会 panic；ch == nil 判断的是零值 channel，和已关闭的非 nil channel 完全无关；len(ch) == 0 && cap(ch) == 0 只说明无缓冲且空，和关闭状态毫无关系。
真正能用的，只有接收时的双值语法：v, ok := 。这不是技巧，是语言契约：ok 为 false 的那一刻，你才被保证「该 channel 已关闭，且所有已发送数据（含缓冲区）都已被读完」。
select 中必须每个 case 都检查 ok，否则逻辑错乱
在多 channel 场景下，一旦某个 ch 被关闭，它在 select 中会持续满足接收条件——每次都会立即返回零值 + ok == false。如果不检查 ok，就会把关闭当成有效数据处理，导致业务逻辑崩溃或无限循环。
- 错误写法：
case msg := —— 无法区分是真数据还是关闭信号 - 正确写法：
case msg, ok := ，然后立刻if !ok { break }或return - 若需继续监听其他 channel，不能直接
break，而要用带标签的break LOOP或显式continue
for range 不等于“立刻感知关闭”，它要等缓冲区清空
for v := range ch 看似自动检测关闭，其实底层就是不断执行 v, ok := 并在 ok == false 时退出。但它只在「下一次尝试接收」时才触发退出判断。
这意味着：
- 如果
ch是带缓冲的，且关闭前已写入 5 个值，for range会完整读出这 5 个值后才退出 - 如果你需要「一收到关闭信号就停」（比如释放资源、上报状态），
for range不够及时，必须改用for { select { case v, ok := - 若发送方从不
close(ch)，for range就永远阻塞——这不是 bug，是设计使然：它依赖发送方明确结束信号
unsafe 检查 closed 字段？别碰，它不是 API，是实现细节
有人用 unsafe.Pointer 强转 *runtime.hchan 并读取 closed 字段，看似“零开销检测”。但这完全不可靠：
-
runtime.hchan结构体未导出，字段顺序/大小/对齐在不同 Go 版本甚至 GC 模式下都可能变化 - Go 官方明确不承诺其稳定性，2026 年的
go1.26已将closed改为位字段 + mutex 保护，直接读取会得到未定义值 - 即使读出来是 1，也不能保证后续发送不会 panic——因为 close() 原子性只保“置标志”，不保“唤醒完成”
真正难的从来不是怎么查，而是接受协作前提：channel 关闭不是状态，是动作；检测不是目的，是协作契约的一部分。如果你发现自己总想“提前查”，大概率该换用 context.Context 了。
