关闭后的 channel 写入必 panic，读取不会 panic 但需通过 ok 判断是否已关闭；裸读 v :=
关闭后的 channel 写入必 panic，读取不会 panic 但必须靠 ok 判断是否已关；裸读 v := 会安静地一直拿到零值，根本无法退出循环。
向已关闭的 channel 写入一定会 panic
只要对已关闭的 chan 执行 ch ，Go 运行时立刻抛出 <code>panic: send on closed channel。这个 panic 不可 recover，也不看缓冲区大小、不看有没有 goroutine 在读——哪怕刚 close(ch) 就写，也崩。
常见错误现象：
- 多个生产者 goroutine 共享一个 channel，各自判断“我发完了”，都调用
close(ch)→ 第二次close就 panic - sender 因 panic 或提前 return 没走到
close(ch)，receiver 却误以为该关了，自己去关 →panic: close of closed channel
根本原因：关闭是终态操作，和 sync.Mutex.Unlock() 类似，重复关闭非法。正确做法是只由**唯一发送方**负责关闭；多 sender 场景下必须用 sync.Once 或额外协调 channel（如 done chan struct{}）来确保仅一次关闭。
从已关闭的 channel 读取不会 panic，但裸读会卡死
关闭后读取行为分两段：
立即学习“go语言免费学习笔记（深入）”；
- 先读完缓冲中剩余数据（
ok == true） - 缓冲读完后，每次读都非阻塞返回零值 +
ok == false
关键陷阱在于：v := 永远无法感知关闭，因为 <code>v 会安静地变成 0、""、nil 等零值，程序可能无限循环。
常见错误写法：
for {
v := <-ch // 错！v 始终是零值，但 ok 被忽略
process(v)
}正确写法必须用双值接收：
v, ok := <-ch
if !ok {
break // 明确退出
}
process(v)特别注意：chan struct{} 关闭后读到 struct{}{}, false，零值和关闭强绑定，但逻辑仍要靠 ok 驱动，不能只判 v == struct{}{}。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
for range ch 自动退出，但前提是 channel 真被关了
for v := range ch 内部等价于持续执行 v, ok := 并在 <code>ok == false 时退出。它安全、简洁，但有个硬依赖：sender 必须主动调用 close(ch)。
如果 sender 忘关、误关、或根本没关（比如用 context.WithCancel 控制生命周期），for range 就会永久阻塞。
适用场景：
- 读完全部再退出（典型 producer-consumer 模式）
- sender 是单 goroutine 且能确定所有数据已发完
不适用场景：
- 多 sender 无法协调谁来关
- 需要配合超时、select 多路复用、或中途条件退出
此时应改用 for-select + ok 检查模式。
有缓冲和无缓冲 channel 关闭后读取行为一致吗
行为逻辑一致，但初始表现不同：关键都看缓冲区是否还有未读数据。
- 有缓冲 channel（如
make(chan int, 3)）：关闭后仍可读出已入队的全部缓存值，FIFO 顺序，每次ok == true；读完才开始返回0, false - 无缓冲 channel（如
make(chan int)）：关闭时若无 goroutine 正在阻塞发送，则缓冲区为空，**首次读就返回0, false**
无论缓存大小，关闭后写操作都会 panic: send on closed channel；关闭后读不 panic、不阻塞，这是 Go 明确保证的安全行为。
最容易被忽略的点是：不是“关早了”出问题，而是“关晚了还继续读”——比如 sender 已关，但 receiver 的 select 分支卡在其他 case，迟迟没轮到读 channel，导致业务逻辑延迟响应关闭信号。这种情况下，应在 select 中显式监听关闭，或用 default 配合重试避免饥饿。
