关闭后可安全读取：先读完缓存数据（ok=true），再读返回零值+false；必须用 v, ok :=
关闭后读取返回零值，但不等于“没数据”
关闭 channel 后读取不会 panic，但返回值不可直接当作有效数据用。比如 int 类型 channel 关闭后， 会返回 <code>0；string 类型返回 ""；*T 返回 nil。这些全是合法零值，和正常发送的 0、""、nil 完全无法区分。
必须用双返回值语法判断：v, ok := 。只有 <code>!ok 才表示 channel 已关且无剩余数据。单写 v := 会把关闭后的零值误认为是有效输入，这是最常见逻辑错位源头。
“先读后关”不是原子操作，竞态真实存在
很多代码想当然地认为：只要在写入 goroutine 里先读完所有数据，再 close(ch)，接收端就一定安全。但现实是，读和关之间没有同步保障。
- 写入 goroutine 可能刚读完缓冲区最后一项，还没执行
close()，接收端就已进入for range ch并退出 - 更危险的是：写入 goroutine 在
close(ch)后，仍有未调度完成的ch 正在排队——尤其在无缓冲 channel 上，这会导致 <code>panic: send on closed channel - 多个写入者时，哪怕每个都“先读后关”，也完全无法避免竞态，因为没人知道谁是最后一个
真正安全的做法是：由唯一写入方（通常是启动 producer 的 goroutine）在确认所有发送完成后再 close()，或改用 sync.WaitGroup 等待所有写入结束。
立即学习“go语言免费学习笔记（深入）”；
for range 自动退出，但依赖的是“关闭 + 缓冲清空”两个条件
for v := range ch 看似万能，但它退出的时机是：channel 关闭 且 所有已发送数据（包括缓冲中残留）都被读完。这两个条件缺一不可。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
常见翻车点：
- 关闭过早：写入还没发完就
close()，range提前退出，部分数据永远卡在缓冲里 - 关闭过晚：写入 goroutine 卡在
ch （比如无缓冲 channel 对端阻塞），<code>range永远等不到关闭信号 - nil channel：如果
ch是nil，for range ch会永久阻塞，不报错也不退出
所以不能只靠 range 做安全阀，得配合写入端生命周期管理，比如用 context.Context 控制超时或取消。
关闭后还能读多少次？答案是“无限次”，但毫无意义
一旦 channel 关闭，后续任意次数的 都会立即返回零值 + <code>false，不阻塞、不 panic、不消耗资源。这不是 bug，是 Go 运行时的明确设计。
但这也意味着：如果你在循环里没检查 ok，只是反复 ，就会陷入无限读零值的死循环。而 <code>for range 能自动退出，正是因为它底层隐含了 ok == false 的退出判断。
最容易被忽略的一点是：关闭动作本身不“推送”任何值，它只是把 channel 置为“可读尽”状态。零值是读操作在无数据时的语言级 fallback，不是 close() 写进去的。
