close() 是原子操作，但仅保证关闭动作本身线程安全，不解决多个生产者竞争关闭导致的 panic 或逻辑竞态问题。
close() 是原子操作，但关闭行为本身不保证写入完成
调用 close(ch) 本身是原子的：运行时会加锁、置 closed=1、唤醒所有等待的 goroutine。但这只解决「关」这一步，**不解决「谁该关」「何时关」的逻辑竞态**。高并发下，如果多个 producer 都认为自己是最后一个写入者而调用 close()，就会触发 panic: close of closed channel；若一个 producer 关闭后另一个仍在执行 ch ，则触发 panic: send on closed channel。
多写入者场景下，close() 的竞态风险远大于原子性收益
Go 的 channel 内部用 mutex 保护读写和关闭，所以单次 close() 不会因并发调用而损坏内存——但它无法阻止你写错逻辑。真实问题从来不是「close() 是否线程安全」，而是：
- 多个 goroutine 同时写入时，没有全局共识机制判断「是否真没数据要写了」
-
sync.Once只防重复关，不防「关早了」（还有 goroutine 持有 channel 引用并试图发送） - 用
len(ch) == 0 && cap(ch) > 0判断是否可关？不可靠——缓冲区可能刚被填满，下一个ch 就阻塞
高并发中更安全的替代方案：用 context.Done() 主动退出，而非依赖 close()
绝大多数需要「通知停止」的场景，close() 是过载设计。正确做法是让接收端监听 ，发送端在收到 ctx.Done() 后停止写入，并让主控 goroutine 等待所有 sender 结束再决定是否关（通常也不必关）：
ctx, cancel := context.WithCancel(context.Background()) defer cancel() <p>// 启动多个 sender for i := 0; i </p><p>// 等待全部 sender 退出后再 close（仅当语义必需时） wg.Wait() close(ch)</p>
注意：这里 close(ch) 是可选的，for range ch 能正常退出的前提，是发送端已全部退出且无 goroutine 卡在 ch 上——而这由 ctx + sync.WaitGroup 保障，不是靠 close() 本身。
真正容易被忽略的点：channel 关闭后，接收端仍可能读到零值
从已关闭的 channel 读取，只要缓冲区还有数据，v, ok := 中的 ok 仍为 true；只有缓冲区清空后，后续读取才返回零值且 ok == false。这意味着：
-
for range ch不会在close()后立刻退出，它得等缓冲区耗尽 - 若你用
select { case v, ok := 做手动退出，必须配合循环逻辑，否则一次就跳出 - 用
len(ch)查剩余数据量？不准——它只反映缓冲区当前元素数，不包含正在排队的发送 goroutine
