往已关闭的 chan 写数据会直接 panic：运行时触发“send on closed channel”，程序崩溃；这是不可恢复的致命错误，旨在强制暴露发送与关闭的时序冲突。
往已关闭的 chan 写数据会直接 panic
Go 运行时不允许向已关闭的 chan 发送任何值，ch 会立刻触发 <code>panic: send on closed channel。这不是可恢复的错误，也不是返回 false 的失败状态——它属于编程逻辑错误，必须在设计阶段规避。
常见错误场景包括：
- 多个 goroutine 共享一个
chan并各自尝试关闭或写入 - 使用
recover()封装写操作，误以为能“优雅降级” - 在
select中未判空就写入，而通道可能已被其他协程关闭
Go 的设计意图很明确：关闭 chan 是单向终止信号，写入行为违反该语义，runtime 直接中断以暴露问题。别试图绕过 panic，而应重构所有权模型。
从已关闭的 chan 读数据不会 panic，但需检查 ok
关闭后的 chan 仍可安全读取，直到缓冲区耗尽。每次 返回两个值：<code>val 和 ok。只要 ok 为 true，说明读到了有效数据；一旦 ok 变为 false，代表通道已关闭且无剩余数据，后续读取将始终返回该类型的零值（如 int 是 0，string 是 ""）。
典型误用：
- 忽略
ok直接使用val，导致把零值误当作有效数据处理 - 用
for { 循环读取却不判断 <code>ok，造成无限循环或逻辑错乱 - 对无缓冲
chan关闭后立即读取，误以为一定能拿到值（实际可能还在发送途中）
正确做法是始终用双赋值形式，并在 ok == false 时退出读取逻辑，或改用 for range ch —— 它自动处理关闭语义。
close() 只能调用一次，且应由唯一写入者负责
重复调用 close(ch) 同样触发 panic：panic: close of closed channel。这说明 close 不是幂等操作，而是有明确语义的生命周期终结动作。
关键约束：
- 只有发送方（写入者）有权关闭
chan；接收方关闭是逻辑错误 - 多个写入 goroutine 共享同一
chan时，不能随意关闭——必须协调谁来关、何时关 - 若无法保证单写者，应避免直接
close，改用sync.WaitGroup或context控制退出
实践中，最稳妥的方式是让生产者 goroutine 自己 defer close(ch)，并在所有发送完成后再关闭。若需提前中止，用 select 配合 done 通道退出，不关闭 ch。
nil chan 和已关闭 chan 的行为差异极易混淆
两者都涉及“不可用”，但行为完全不同：nil chan 在 select 中永远阻塞，在单独读写时永久挂起（最终死锁）；而已关闭的 chan 在 select 中仍可参与（读分支立即就绪），单独读取也立即返回。
容易踩坑的地方：
- 声明了
var ch chan int却忘记make，结果整个 goroutine 卡死 - 把
ch = nil当作“安全清空通道”，却没意识到它会让for range ch永久阻塞 - 在
select中动态禁用某通道时，误用close()而非置nil，导致后续写 panic
记住：nil 是未初始化，关闭是已终结；前者是配置错误，后者是通信协议的一部分。它们不是同一类问题，也不能互相替代。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
