发送方，且仅此一人；Go 中 close() 只能由 channel 的发送方调用，接收方调用会 panic：“close of receive-only channel”，这是语言强制约束，编译器禁止对只接收通道调用 close。
谁该调用 close()？发送方，且仅此一人
Go 中 close() 只能由 channel 的**发送方**调用，接收方调用会直接 panic：panic: close of receive-only channel。这不是风格问题，是语言强制约束——编译器甚至不让你写出 close(ch)，如果 ch 类型是 （只读）。
更关键的是：即使类型允许（比如 chan int），也**必须确保只有一个 goroutine 负责关闭**。多生产者场景下，若每个生产者都自作主张 close()，第二次调用就会 panic：panic: close of closed channel。
- ✅ 正确做法：由协调者（如主 goroutine）或唯一发送方负责关闭；多生产者时，用
sync.Once包一层，或通过额外的done信号统一通知关闭时机 - ❌ 常见错误：在消费者 goroutine 里看到
!ok就顺手close(ch)—— 这不仅非法，还会让其他还在发数据的生产者崩溃 - ⚠️ 注意：
close()不等于“释放资源”，channel 本身会被 GC 回收，close()的唯一语义是“**不再有新数据了**”
不关 channel 会怎样？Goroutine 泄漏最常见原因
如果你用 for range ch 消费数据，而发送方从不 close(ch)，那这个 for 循环永远不会退出——它会永远阻塞在 上，对应 goroutine 永久存活，形成泄漏。
这种泄漏在压力测试或长周期服务中特别隐蔽：内存不暴涨，CPU 不飙升，但 goroutine 数持续增长，直到调度器不堪重负。
- ✅ 安全底线：只要用了
for range，且没有其他退出条件（比如超时、context 取消），就必须确保发送端会在某个明确时机调用close() - ❌ 错误假设：“我用带缓冲 channel，发完就不管了”——缓冲区清空后，
range仍会阻塞等待更多数据，除非 channel 被关闭 - ? 替代方案：不用
range，改用val, ok := + 显式判断!ok退出，但依然要有人负责close()，否则ok永远为true
什么时候可以不关？三种安全不关的场景
不是所有 channel 都需要 close()。强行关闭反而增加出错风险。以下情况可放心不关：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- ✅ 一次性通信：比如
done := make(chan struct{})，只用来通知“事干完了”，发送方发一个值就结束，接收方收到即走，之后没人再读写，GC 自动回收，关不关没意义 - ✅ 私有 channel：只在一个 goroutine 内创建、使用、丢弃，无任何其他 goroutine 引用（包括未启动的 goroutine），生命周期完全可控，无需
close() - ✅ 用
context.Context控制生命周期：比如 worker 从dataCh读数据，但退出逻辑完全由驱动，此时dataCh是否关闭不影响退出，关了反而可能让早先的发送 panic
判断依据很简单：**有没有 goroutine 在等“数据结束”这个信号？没有，就不需要 close()。**
多生产者怎么安全关？别靠猜，用显式同步
多生产者 + 单/多消费者是最容易翻车的场景。没人知道谁发最后一个数据，自然没人敢贸然 close()。
典型错误是让每个生产者发完自己那份就 close()，结果第二个生产者一关就 panic。正确解法不是“谁最后谁关”，而是“**谁都不关，由外部协调者关**”。
- ✅ 推荐模式：用
sync.WaitGroup计数生产者完成，主 goroutinewg.Wait()后再close(ch) - ✅ 更现代做法：用
context.WithCancel或context.WithTimeout，让所有生产者监听同一个ctx.Done()，主 goroutine 在全部退出后关闭 channel - ❌ 避免“计数+原子操作”手工管理关闭：易竞态、难验证，不如交给
WaitGroup这种标准原语
真正麻烦的从来不是“怎么关”，而是“怎么确认所有数据已发出、且无人再试图发送”。这一点，光看 channel 本身是看不出的，必须靠外部同步机制锚定。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
