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 <p>注意这里没有「if ch 不是 closed 就发」的判断逻辑。如果 <code>ch</code> 在某个 <code>case ch 执行前被其他 goroutine 关闭，该次发送会 panic —— 这说明设计错了：要么不该允许多方关，要么写权限没收敛。</code></p> <p>若需更柔性控制（比如允许部分写失败后继续），应改用 <code>nil</code> 通道技巧：</p> <ul> <li>定义 <code>writeCh := ch</code> </li> <li>在 <code>select</code> 中写 <code>case writeCh </code> </li> <li>收到停止信号后，执行 <code>writeCh = nil</code>，之后该 case 永远阻塞，不会 panic</li> </ul> <h3>最容易被忽略的点：关闭 ≠ 可写，而是一次不可逆承诺</h3> <p>很多开发者卡在「我想发完最后一个值再关，但怕关早了丢数据」，其实问题不在技术细节，而在语义混淆：channel 关闭不是「我刚发完」的同步点，而是「我承诺不会再发」的声明。只要还有 goroutine 认为自己能发，或者接收方还没按约定退出，这个承诺就尚未完成。</p> <p>所以真正要做的不是写个函数去 <code>IsChanClosed()</code>，而是厘清三件事：</p> <ul> <li>谁创建 channel，谁拥有写权限和关闭权</li> <li>发送完成的判定条件是什么（是循环结束？是收到 done 信号？还是某次 send 返回？）</li> <li>接收方如何响应——是用 <code>for range</code> 等它自然退出，还是用 <code>v, ok :=</code> 主动感知并清理资源</li> </ul> <p>绕开这三点去搞「check-before-send」，只会把竞态从运行时搬到逻辑里，而且更难 debug。</p></int>
