Golang安全关闭channel方法详解

<p>只有发送方能调用 close() 且仅一次；接收方调用会导致编译失败或 panic；Go 类型系统在编译期限定 close() 仅接受 chan T 或 chan<- T。</p>

只能由发送方关闭，且必须确保只关一次；接收方永远别碰 close()，否则编译失败或运行时 panic。

谁有资格调用 close()？

Go 的类型系统在编译期就锁死了权限：close() 只接受 chan T 或 chan<- T，拒绝 <-chan T（只读通道）。这意味着：

• 如果你函数参数是 ch <-chan int，close(ch) 直接报错：invalid operation: close(ch) (cannot close receive-only channel)
• 真正能关 channel 的，是那个创建它、还握着双向或只写类型变量的 goroutine
• 常见错误：把 channel 封装进结构体后暴露 Close() 方法，却没检查内部是否已是只读类型

为什么重复 close() 会 panic？

Go 运行时不提供“是否已关闭”的查询接口，也不做幂等处理——close(ch) 是个不可逆的原子信号。一旦触发，再次调用立刻崩溃：panic: close of closed channel。

• 典型踩坑场景：多个 worker goroutine 都监听 ctx.Done()，各自判断“该收尾了”，然后都执行 close(ch)
• 安全解法：用 sync.Once 包一层，比如 once.Do(func() { close(ch) })
• 别把 once.Do() 放在 for 循环里——它本意就是“只做一次”，放错位置等于没保护

接收方怎么知道 channel 关了？

不能靠 <-ch 单值接收猜，必须用双值语法：v, ok := <-ch。其中 ok == false 才代表 channel 已关闭且缓冲区为空。

• 常见错误：int channel 发了 0，接收方单值读到 0 就以为结束了——其实只是数据，不是关闭信号
• for v := range ch 是语法糖，底层自动做 v, ok 判断，适合“消费全部数据”的场景
• 但若你需要“一检测到关闭就立刻退出”（比如清理资源），就得手写 select + ok 判断，不能依赖 range

sender 提前退出时怎么不丢数据？

真实系统里，发送方可能因超时、错误或 ctx.Done() 中断。这时如果直接 close(ch)，还没发完的数据就丢了。

• 危险写法：用 select 发送，case <-done: 分支里立刻 close(ch) —— 剩余 items 全被跳过
• 安全写法：先确保所有要发的值都成功写入（缓冲够大 or 接收方活跃），再统一 close(ch)
• 更健壮的替代：不用关闭，改用 context.Context 控制生命周期，或加哨兵值（如 nil）标记流结束

最常被忽略的一点：channel 关闭不是“释放资源”的动作，而是“发信号”的动作。它本身不回收内存，也不终止 goroutine——goroutine 是否退出，取决于你有没有在接收逻辑里响应 ok == false 或 ctx.Done()。信号发了，没人听，照样卡住。