关闭channel前必须确认唯一写入者，仅由最后一个潜在写入goroutine调用close()；多写入者竞态关闭会panic；应由producer统一关闭，worker只读；优先用context控制生命周期而非依赖close。
关闭 channel 前必须确认「谁是唯一写入者」
Go 中 close() 只能由写入方调用，且只能调一次；如果多个 goroutine 同时写入，又各自判断条件去 close()，必然触发 panic：panic: close of closed channel 或更隐蔽的竞态（如写入已关闭的 channel 导致 send on closed channel）。
典型错误场景：启动多个 worker goroutine 从同一个 chan int 读取，又让每个 worker 在退出前尝试 close(ch) —— 这完全违背 channel 设计契约。
- 只有明确知道「当前 goroutine 是该 channel 的最后一个潜在写入者」，才可调用
close() - 常见安全模式：由启动写入逻辑的 goroutine（通常是主协程或单独的 producer）负责关闭，worker 全部只读
- 若需动态决定关闭时机（如超时、错误聚合），用
sync.Once包裹close()，但要注意它不解决写入竞态，仅防重复关
用 select + done channel 替代盲目关闭
很多场景其实根本不需要关闭 channel —— 尤其是作为信号或事件流使用时。关闭 channel 的主要语义是「通知接收方：不会再有新值了」，但它不是资源释放开关。误以为「关了 channel 就算清理完毕」，常导致 goroutine 泄漏。
例如：一个长期运行的监听 goroutine 从 ch 读数据，同时监听 ctx.Done()。如果仅靠 close(ch) 试图让它退出，但没同步通知它停，它可能卡在 <-ch 上永远等下去。
立即学习“go语言免费学习笔记（深入）”；
- 优先用
context.Context控制生命周期，select中同时监听<-ch和<-ctx.Done() - 接收端无需依赖
ok := <-ch判断是否关闭，而是由 context 主动中断 - 发送端在收到
ctx.Done()后停止写入即可，不必强求close()—— channel 本身无引用后会被 GC
range 遍历 channel 的隐含前提与陷阱
for v := range ch 确实会在 channel 关闭且缓冲区为空时自动退出，但它不是万能安全阀。一旦你依赖这个行为，就必须确保：关闭动作发生在所有写入完成之后，且没有写入者还在执行 ch <- v。
常见翻车点：关闭前未等待正在写入的 goroutine 结束，比如用 go func() { ch <- x }() 启动写入，紧接着就 close(ch) —— 写入可能仍在排队，range 已退出，但 goroutine 卡在发送上（尤其当 channel 无缓冲时）。
- 若必须用
range，写入端应通过sync.WaitGroup或context确保所有发送完成后再close() - 无缓冲 channel 上，
range退出后仍有 goroutine 尝试发送，会直接 panic；有缓冲的则可能静默阻塞，直到被其他逻辑唤醒或程序结束 - 对「可能永远不关闭」的 channel（如日志流、事件总线），别用
range，改用for { select { ... } }
关闭 channel 并不等于释放底层资源
channel 本身是 Go runtime 管理的结构，关闭后内存不会立刻回收，它的缓冲区内容仍存在，直到所有接收操作完成。更重要的是：关闭 channel 完全不影响持有该 channel 的 goroutine 是否存活。
真正泄漏的根源，往往是忘记停止那些「阻塞在 channel 操作上」的 goroutine。比如一个 goroutine 死循环 select { case v := <-ch: ... }，而 ch 被关闭了 —— 它不会退出，因为 <-ch 在关闭后仍能立即返回零值（除非加 default 或用 context）。
- channel 关闭只是通信状态变更，不是 GC 触发器，也不是 goroutine 终止令
- 资源释放的关键是让 goroutine 自然结束：要么通过
context退出循环，要么用sync.WaitGroup显式等待，或者设计成有限次处理 - 用
pprof查 goroutine 泄漏时，看到大量处于chan receive状态的 goroutine，基本可断定是 channel 生命周期和控制流没对齐
事情说清了就结束