for range ch 必须等通道关闭才退出，因为它持续尝试接收值而非仅读取缓冲区；即使发送goroutine已退出且缓冲区为空，未关闭通道仍导致range永久阻塞等待关闭信号。
for range ch 为什么必须等 channel 关闭才退出
因为 for range 不是“读完缓冲区就停”，而是持续尝试从 ch 接收，直到收到关闭信号。未关闭时，哪怕缓冲区已空、发送 goroutine 已退出，range 仍会阻塞在 `fatal error: all goroutines are asleep - deadlock!。
常见错误现象：
- 主 goroutine 卡在
for range ch，程序不退出 - 用
select+default发送数据，误以为“没发”=“结束了”，其实ch还开着 - 多个生产者 goroutine，只关了一次，其余还在写 → panic: send on closed channel
根本原因：Go 运行时把 for range ch 编译为类似 for { v, ok := 的逻辑，而 <code>ok == false 仅在 channel 关闭后才稳定返回。
谁该调用 close(ch)：发送端唯一责任
接收端调用 close(ch) 会直接 panic；多个发送端同时关也会 panic。只有明确知道“所有数据都发完了”的那一方，才有资格关。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 单个生产者 goroutine：发完最后一项后立刻
close(ch) - 多个生产者（如 worker pool）：用
sync.WaitGroup等待全部完成，再由主 goroutine 关 - 无法确定是否发完（如流式日志、实时事件）：别关
ch，改用context.Context或额外的done chan struct{}通知消费者停止
切勿在接收端检查 len(ch) == 0 && cap(ch) > 0 就去关 —— 这既不可靠，也违反 Go 并发模型的设计契约。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
关闭后的 channel 还能读，但不能再写
close(ch) 后， 仍可安全接收，每次返回零值 + <code>false（例如 0, false 或 "", false）；但任何对 ch 的发送操作都会立即 panic。
这直接影响遍历行为：
-
for range ch自动忽略零值，只在关闭后退出，无需手动判断ok - 若用
v, ok := 手动接收，需显式检查 <code>!ok才能退出循环 - 重复调用
close(ch)（哪怕只多一次）也会 panic：close of closed channel
注意：for range 的“自动退出”不等于“自动跳过零值”——它只是不再等待新值，已缓存或正在传输的数据仍会按序吐出。
range 和 for-select 在生命周期控制上的本质区别
for range ch 是被动模型：它只响应关闭信号，不能主动中断、超时或根据业务条件提前退出；for {} select{} 是主动模型：你可以混入 time.After、ctx.Done()、其他 channel 事件。
选哪个？
- 纯消费所有数据，且发送端可控 → 无脑用
for range ch - 需要超时、取消、或边读边处理（比如每读 10 条 flush 一次）→ 必须用
select+ok检查 - 不要试图在
for range里嵌套select做非阻塞发送 —— 那已经脱离了range的设计本意
最易被忽略的一点：即使你用了 select，只要最终目的是“等所有数据来完”，仍得靠发送端关 channel；否则 case 里的 <code>ok 永远不会变 false。
