向已关闭的 channel 发送数据必然 panic，错误信息固定为 panic: send on closed channel；这不是偶发异常，而是 go 运行时强制终止 goroutine 的硬性约束——它在告诉你：写入与关闭的职责或时序已经错乱。
向已关闭的 channel 发送数据必然 panic，错误信息固定为 panic: send on closed channel；这不是偶发异常，而是 Go 运行时强制终止 goroutine 的硬性约束——它在告诉你：写入与关闭的职责或时序已经错乱。
为什么 ch 一关就崩，不能加个判断再发？
Go 没有提供线程安全的 IsClosed() 或类似接口，所有“先检查再发送”的尝试都存在竞态窗口：检查时未关，下一纳秒就被 close()，接着 ch 就 panic。用 <code>sync.Mutex 或原子变量包一层看似安全，实则引入额外同步开销，且无法覆盖所有并发路径（比如多个 sender 分散在不同 goroutine 中）。更关键的是，这种思路本身违背 Go 的 channel 设计哲学——关闭是终结信号，不是状态开关。
- 运行时 panic 是故意设计的“高亮报错”，不是缺陷，而是提醒你：生命周期管理逻辑有问题
-
recover()捕获该 panic 属于反模式：掩盖问题、增加栈展开开销、破坏错误传播语义 - 真正该做的，是让发送操作在 channel 关闭后“不可选”，而不是“选中后失败”
怎么让 select 安全跳过已关闭的 channel？
利用 Go 对 nil channel 的语义：select 中值为 nil 的 case 会被永久忽略，不会阻塞，也不会 panic。核心是把实际 channel 赋给一个局部变量，并只在允许写入时才赋值。
示例：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func writer(done
-
writeCh初始为nil，若done已就绪，default分支不执行，writeCh保持nil - 第二个
select中，writeCh 因 <code>writeCh == nil被跳过，不会 panic - 全程无锁、无原子操作，纯靠 channel 原语实现线程安全
多个 goroutine 写同一个 channel，谁来关？
必须由**唯一确定的 goroutine** 执行 close()，通常是最后一个可能写入的 sender，或主控 goroutine。多个 goroutine 各自 defer close(ch) 是高频翻车点，会触发 panic: close of closed channel。
- 用
sync.Once封装关闭逻辑，确保只关一次：var once sync.Once; once.Do(func() { close(ch) }) - 若生产者是动态启停的（如 worker 池），优先用
context.Context驱动退出，而非依赖close()通知 - 接收方绝不可调用
close()——它不知道是否还有其他 sender 在写，强行关等于埋雷 - 不关
channel通常不会泄漏：GC 会回收无人引用的 channel；但若用for range ch，不关会导致循环永不退出
关闭后还能读吗？怎么读才不踩坑？
能读，但必须用 v, ok := 判断；裸读 <code>v := 会静默拿到零值（如 <code>0、""、nil），根本无法区分是业务数据还是关闭占位符。
-
ok == false表示 channel 已关且缓冲区为空；ok == true才代表读到有效数据 - 有缓冲 channel 关闭后，仍可读出所有已入队数据（FIFO），读完才开始返回
0, false - 无缓冲 channel 关闭后若无阻塞发送者，则首次读即返回
0, false -
for v := range ch内部隐式做了ok检查，所以能自动退出；但前提是所有 sender 确实已停止且close()已执行
最容易被忽略的细节是：关闭 channel 不等于所有写入 goroutine 已退出。若你刚 close(ch) 就认为万事大吉，而某个 sender 正卡在 ch 上（尤其无缓冲 channel），它会在下一次调度时 panic。必须用 <code>sync.WaitGroup 或 context 显式等待所有写入方真正结束，再关。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
