关闭 channel 的安全性核心在于：只由发送方关闭，且确保无 goroutine 正在或即将发送数据；接收方永不关闭，避免 panic。典型做法是发送方在完成发送后调用 close(ch)，使用 sync.Once 或原子操作防止重复关闭；接收方通过 for range 或 v, ok 模式安全读取，不参与关闭。
关闭 channel 的安全性核心在于：只由发送方关闭，且确保没有 goroutine 正在或即将向其发送数据；接收方永远不应关闭 channel，也不应重复关闭。
谁负责关闭？只由发送方关闭
channel 是“单向契约”：发送方承诺不再发数据，接收方据此判断流结束。若接收方误关 channel，其他发送 goroutine 可能 panic（send on closed channel）；若多个发送方竞争关闭，会触发 panic（close of closed channel）。
- 明确 channel 的所有权：创建 channel 的 goroutine 或协调者，应负责管理其生命周期
- 避免跨 goroutine 传递关闭权限；如需协同关闭，用额外的 done channel 或 sync.Once 封装关闭逻辑
- 典型模式：启动一个 sender goroutine，它在完成所有发送后调用 close(ch)
如何避免重复关闭和误关？加一层保护
Go 运行时对重复 close 会直接 panic，无法 recover。因此不能依赖“try-close”，而应在逻辑层保证只关一次。
- 使用 sync.Once：封装 close 操作，天然幂等
- 用原子布尔值（如 sync/atomic.Bool）标记是否已关闭，关闭前先 CAS 判断
- 不推荐用 defer close(ch) 在多个 goroutine 中——除非你能 100% 确保该 goroutine 是唯一发送方且不会被重复启动
接收方的安全做法：永不关闭，善用 range 和 ok-idom
接收方只需读取、响应 closed 状态，无需、也不应干预 channel 生命周期。
立即学习“go语言免费学习笔记（深入）”；
- 用 for v := range ch {} 自动处理关闭 —— 它会在 channel 关闭且缓冲为空时自然退出
- 单次接收务必用 v, ok :=
- 不要在 select 的 default 分支里 close(ch) —— default 非阻塞，极易导致误关或重复关
异常场景下的健壮性设计
真实系统中，sender 可能因错误、超时、上下文取消而提前终止，此时需安全中断发送并通知接收方。
- 结合 context.Context：sender 监听 ctx.Done()，退出前 close(ch)；receiver 同样监听 ctx.Done() 防止永久阻塞
- 用带缓冲的 channel + 显式哨兵值（如 nil 或自定义 eof）替代关闭，适用于无法控制 sender 生命周期的场景（如插件、回调）
- 若 sender panic，未执行 close，receiver 可通过超时或外部信号判断“流应已结束”，转为 graceful shutdown
基本上就这些。channel 关闭本身不复杂，但容易忽略所有权和时序，引发隐蔽 panic。守住“谁创建、谁关闭”“只关一次”“接收方只读不关”三条线，就能避开绝大多数坑。
