Go中不存在安全可靠的“先检查再发送”模式，因channel关闭是单向承诺而非可探测状态；唯一安全方式是send-or-die：发送方须独占channel所有权并负责其生命周期管理。
为什么不能先 check 再 send
Go 语言中不存在安全、可靠、可竞态容忍的「检查 channel 是否已关闭，再决定是否发送」模式。所有试图在 send 前做状态探测的操作，本质上都违反 channel 的协作契约——关闭不是状态快照，而是单向承诺动作，且接收方无法原子地观察到「即将关闭」或「刚刚关闭」的瞬时点。
常见错误包括：
- 用
reflect或 runtime 字段读取内部closed标志：字段未导出、结构随版本变化、读取结果不可靠，甚至直接 panic - 用
select+default非阻塞接收来“探活”：会真实消费一个值（若存在），破坏数据流语义；若 channel 有缓冲且未关，探测成功但后续 send 仍可能因调度延迟撞上关闭 - 依赖
len(ch) == 0或cap(ch) == 0：它们只反映缓冲区当前容量与待取数量，与关闭状态完全无关
真正能用的 only-safe 模式是 send-or-die
Go 要求你接受一个事实：向 channel 发送数据，要么成功，要么 panic。这个 panic 不是 bug，而是设计信号——它强制你在逻辑层解决「谁关、何时关、谁负责写」的问题，而不是靠运行时兜底。
所以唯一安全路径是：让发送行为本身成为生命周期管理的一部分。具体做法：
- 发送方必须拥有 channel 的所有权，且是唯一写入者；关闭前确保所有
ch 已完成（包括最后一个） - 多写者场景下，不尝试「检查后发」，而是把写通道设为
nil：select中该 case 永远不就绪，自然跳过发送 - 需要响应外部取消（如
ctx.Done()）时，用select同时监听ctx.Done()和写通道，一旦取消信号到达，立即退出 goroutine，**不尝试发最后一句** - 绝不在
recover()中捕获send on closed channel来“降级处理”——这掩盖了所有权混乱，且 recover 成本高、不可预测
select 中写操作的正确写法（避免误判关闭）
当你必须在一个 select 里做发送，并希望它在 channel 关闭时不 panic，唯一合法方式不是「检查关闭」，而是让发送分支失效。例如：
func safeWriter(ch chan<int>, stopCh <-chan struct{}) {
for i := 0; i < 10; i++ {
select {
case ch <- i:
// 正常发送
case <-stopCh:
return // 外部要求停止，直接退出，不发也不关
}
}
close(ch) // 所有发送完成，由本 goroutine 关闭
}注意这里没有「if ch 不是 closed 就发」的判断逻辑。如果 ch 在某个 case ch <- i 执行前被其他 goroutine 关闭，该次发送会 panic —— 这说明设计错了：要么不该允许多方关，要么写权限没收敛。
若需更柔性控制（比如允许部分写失败后继续），应改用 nil 通道技巧：
- 定义
writeCh := ch - 在
select中写case writeCh <- x: - 收到停止信号后，执行
writeCh = nil，之后该 case 永远阻塞，不会 panic
最容易被忽略的点：关闭 ≠ 可写，而是一次不可逆承诺
很多开发者卡在「我想发完最后一个值再关，但怕关早了丢数据」，其实问题不在技术细节，而在语义混淆：channel 关闭不是「我刚发完」的同步点，而是「我承诺不会再发」的声明。只要还有 goroutine 认为自己能发，或者接收方还没按约定退出，这个承诺就尚未完成。
所以真正要做的不是写个函数去 IsChanClosed()，而是厘清三件事：
- 谁创建 channel，谁拥有写权限和关闭权
- 发送完成的判定条件是什么（是循环结束？是收到 done 信号？还是某次 send 返回？）
- 接收方如何响应——是用
for range等它自然退出，还是用v, ok :=主动感知并清理资源
绕开这三点去搞「check-before-send」，只会把竞态从运行时搬到逻辑里，而且更难 debug。
