唯一可靠方式是用 <-ch 多值接收并检查 ok 值：关闭后返回零值且 ok 为 false，未关闭时 ok 为 true；ch == nil 或反射判空均无效。
怎么安全判断一个 channel 是否已关闭
Go 语言没有提供直接的 isClosed() 函数，也不能用 len(ch) == 0 && cap(ch) == 0 判断——这只能说明 channel 为空且无缓冲，和是否关闭完全无关。唯一可靠的方式是尝试接收，并配合「多值接收」语法观察第二个返回值（ok 值）。
用 <-ch + ok 模式检测关闭状态
channel 关闭后，继续接收会立即返回零值，且 ok 为 false；未关闭时 ok 为 true。这是唯一被语言规范保证的行为。
常见错误现象：if ch == nil 或 reflect.ValueOf(ch).IsNil() 都不能反映关闭状态——nil channel 和已关闭的非 nil channel 是两回事。
- 永远不要在 select 中仅靠
case x := 判断关闭，因为可能阻塞或漏掉关闭信号 - 如果只是想“探查”是否关闭，又不想丢数据，必须用带 ok 的短变量声明：
x, ok := - 注意：对已关闭 channel 执行发送操作会 panic，但接收不会；所以检测必须用接收，不能用发送
为什么不能用 recover 捕获关闭后的 send panic 来反推状态
这不是检测手段，而是设计错误。向已关闭 channel 发送会触发 panic，但 recover 成本高、掩盖真实逻辑问题，且无法区分是自己发的还是别人发的导致关闭。
立即学习“go语言免费学习笔记（深入）”；
使用场景举例：worker goroutine 需要优雅退出，主协程关闭 channel 后，worker 应尽快感知并停止循环——这时必须用 val, ok := ，而不是等 panic 再 recover。
- recover 只适用于极少数必须兜底的边界场景，不是 channel 状态检测方案
- 即使 recover 成功，你也失去了“谁关的、何时关的”上下文，后续逻辑更难推理
- 性能上，panic/recover 比普通接收慢 1–2 个数量级，且不可预测
select 中如何避免因 channel 关闭导致的逻辑错乱
当多个 channel 参与 select，其中一个关闭后，它会持续满足接收条件（返回零值 + false），可能造成无限循环或误触发。必须在每个 case 接收后检查 ok。
示例错误写法：
select {
case msg := <-ch:
handle(msg) // 如果 ch 已关闭，这里 msg 是零值，但 ok 信息丢失
}
正确写法：
select {
case msg, ok := <-ch:
if !ok {
return // 或 break loop
}
handle(msg)
}
- 所有涉及 channel 接收的 select 分支，只要该 channel 可能被关闭，就必须用双返回值形式
- 不要把多个 channel 放进同一个 select 然后只检查一个的 ok —— 其他 channel 的关闭仍会导致该分支持续就绪
- 若需等待任意 channel 关闭，可改用
for range ch，它天然处理关闭语义
close(ch) 本身不阻塞，但后续的接收是否立刻拿到 ok == false，取决于是否有 pending 的值或正在阻塞的 sender —— 这意味着“关闭”和“被感知到关闭”之间存在微小时间窗口，业务逻辑得容许这点异步性。 
