关闭channel只能由发送方执行，避免重复关闭和向已关闭channel发送数据引发panic；使用close(ch)后可继续接收，缓存数据读取完毕后返回零值；通过v, ok :=
在Go语言中，channel是实现goroutine之间通信的核心机制。正确处理channel的关闭以及相关panic，对程序的稳定性至关重要。理解何时关闭channel、如何安全接收数据、怎样避免向已关闭的channel发送数据导致panic，是每个Go开发者必须掌握的内容。
关闭channel的基本原则
channel只能由发送方关闭，这是约定俗成的最佳实践。关闭一个nil channel会引发panic，而关闭一个已经关闭的channel也会导致panic，因此要确保关闭操作只执行一次。
使用close(ch)显式关闭channel后，该channel不再允许发送数据，但可以继续接收。如果channel中有缓存数据，接收方仍能读取完这些值，之后的接收操作将返回零值。
- 只在发送侧调用close()
- 避免重复关闭同一个channel
- 接收方不应负责关闭channel
安全地从可能关闭的channel接收数据
从已关闭的channel接收不会引发panic，而是返回对应类型的零值。为了判断数据是否真实发送，可使用双返回值语法：
立即学习“go语言免费学习笔记（深入）”；
v, ok :=
当channel关闭且无剩余数据时，ok为false；否则ok为true。这种方式常用于协程间协调退出。
遍历一个channel时，使用for range会自动在channel关闭后退出循环，适合处理流式数据。
防止向已关闭的channel发送导致panic
向已关闭的channel发送数据会立即触发运行时panic。为避免这种情况，可以采用以下策略：
- 使用select配合default分支实现非阻塞发送，提前检测是否还能写入
- 通过额外的控制channel通知发送方停止操作
- 使用sync.Once确保关闭操作仅执行一次
对于多个生产者场景，建议引入一个专门的“关闭协调”机制，比如由独立的管理协程控制关闭时机。
recover处理channel相关的panic
尽管应尽量避免panic发生，但在复杂系统中仍可考虑使用defer + recover作为防御性措施。例如，在关键的发送操作外层包裹recover：
虽然recover能捕获panic，但它不能恢复程序正常逻辑，仅用于记录日志或优雅退出。最佳做法仍是通过设计规避问题，而不是依赖recover兜底。
基本上就这些。合理规划channel生命周期，明确关闭责任，结合ok判断和select机制，就能写出健壮的并发代码。不复杂但容易忽略细节。
