多生产者场景下不能随便 close(ch)，因为 close() 表示“我发完了且以后谁也别发了”，任一生产者继续发送即 panic；必须由单一协调者（如主 goroutine）在所有生产者退出后关闭，推荐用 sync.waitgroup 或 errgroup.group 确保安全。
多生产者场景下为什么不能随便 close(ch)
因为 close() 不是“通知所有人别发了”，而是“我发完了，且以后谁也别发了”——只要还有一个生产者在往 ch 里 send，close(ch) 就会立刻 panic: send on closed channel。
常见错误是主 goroutine 启动完所有生产者后，马上 close(ch)，完全没等它们结束。哪怕只差一个协程没退出，panic 就发生了。
- panic 不是竞态检测结果，是运行时确定性错误，100% 复现
-
sync.Once包裹close()没用：它拦不住发送行为，只拦第二次close() - 多个生产者“协商谁来 close”属于高危操作，极易漏关或重复关
谁该调用 close(ch)？必须是单一协调者
Go 编译器强制要求：只能由发送方调用 close()，且接收方调用会直接编译失败（panic: close of receive-only channel）。但更关键的是——即使类型允许（如 chan int），也必须确保只有一个 goroutine 执行关闭动作。
- 正确做法：由主 goroutine 或专用协调 goroutine 负责，在确认所有生产者退出后再
close(ch) - 推荐用
sync.WaitGroup：每个生产者 deferwg.Done()，主 goroutine 在wg.Wait()后调用close(ch) - 更现代的替代是
errgroup.Group：它的Wait()自动阻塞直到所有Go()启动的生产者结束，语义更清晰
消费者不能只靠 channel 关闭判断流结束
for range ch 看似简洁，但在多生产者模型中极其危险：一旦 ch 提前关闭，循环立即退出，剩余生产者还没发完的数据就永远卡在缓冲区里，被丢弃。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 根本问题在于：channel 关闭 ≠ 数据全部送达，只是“不再有新数据”
- 消费者应配合
select+donechannel 实现可中断读取，而不是死等range - 若业务逻辑可控，优先用明确计数（如总任务数）+ 带缓冲 channel，比依赖关闭更可靠
v, ok := 仍受关闭时机影响，不解决生产者未完成发送的问题
关闭不是资源释放，不关会泄漏 goroutine
close() 的唯一语义是“发送终止信号”，和内存回收无关——channel 本身由 GC 管理。但它直接影响消费者生命周期。
如果你写 for range ch，而发送端从不 close(ch)，这个循环永远不会退出，goroutine 永久阻塞在 上。这种泄漏隐蔽性强：CPU 和内存无明显增长，但 goroutine 数持续攀升，最终压垮调度器。
真正容易被忽略的是：哪怕用了带缓冲 channel，只要没 close，range 就会一直等下去——缓冲区清空后，它还在等“下一个可能的发送”，而不是自动结束。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
