应由唯一写入方（最后一个可能写入的goroutine）调用close()；多生产者需协调终结者，消费者绝不可关；动态场景推荐context.context而非关channel；for range ch退出需确保所有写入完成且无goroutine阻塞发送。
谁该调用 close()？只允许生产者关，且必须是最后一个
Go 中 close() 只能由 channel 的**唯一写入方**调用——不是“谁先写完谁关”，而是“谁确定自己是最后一个可能写入的 goroutine，谁才有资格关”。否则极易触发 panic: close of closed channel 或更危险的 send on closed channel。
- 多个 producer 并发写入时，绝不能各自判断“我写完了”就
close(ch)；必须协调出一个终结者（比如用sync.Once或主控 goroutine 统一收尾） - consumer 任何时候都不要碰
close()—— 它连 channel 是否还在被写都不知道，关了等于埋雷 - 如果 producer 是动态启停的（比如 worker 池按需拉起），推荐用
context.Context通知退出，而非依赖关闭 channel 来同步生命周期
为什么 for range ch 不是万能退出开关？
for range ch 确实会在 channel 关闭且缓冲区清空后自动退出，但它隐含一个强前提：**所有写入操作已完成，且没有 goroutine 卡在 ch 上**。现实里这个前提常被忽略。
- 常见翻车：用
go func() { ch 启动发送，紧接着就 <code>close(ch)—— 无缓冲 channel 下，goroutine 直接阻塞在发送，而range已退出，造成 goroutine 泄漏 - 有缓冲 channel 也不保险：若缓冲未满，
close()后仍有数据可读，但若 sender 还在往缓冲里塞，就可能 panic - 真正安全的做法：用
sync.WaitGroup等待所有 sender goroutine 显式结束，再close()；或改用select+ctx.Done()主动退出
不关 channel，真的会泄漏或卡死吗？
绝大多数情况下，**不调用 close() 不会导致泄漏或死锁**。channel 本身是引用类型，当无 goroutine 持有它、也无人再读写时，会被 GC 回收。强行关闭反而是 bug 温床。
- 仅当 receiver 依赖
for range自动退出，或需要通过val, ok := 的 <code>ok==false判断流结束时，才需要关 —— 也就是「信号型」或「有限数据流」场景 - 事件通知类 channel（如
done chan struct{}）、控制信号类 channel，通常只需close()一次作广播，且应由发起方唯一关闭 - 如果只是做 goroutine 间同步或传递状态，用
struct{}channel 配合select就够了，根本不需要关
如何检测 channel 是否已关闭？别试了，Go 没提供安全接口
Go 标准库**没有公开、线程安全的函数来判断 channel 是否已关闭**。网上流传的 select { case 类似技巧，只能试探是否“此刻可非阻塞接收”，无法区分“空了”还是“关了”。
val, ok := 中的 <code>ok为false，只在 channel 关闭 *且* 缓冲为空时才成立；若缓冲还有数据，ok仍为true- 试图用 recover 捕获
send on closed channel是反模式 —— panic 是程序错误，不是控制流手段 - 真正可靠的方案：用额外信号（如另一个
closed chan struct{}）或结构体字段显式标记状态，而不是和 channel 的关闭状态耦合
最常被忽略的一点：关闭 channel 的动作，本质是向 receiver 发送一个“终止信号”，但它不解决任何同步问题。是否能安全关闭，取决于你是否真正掌控了所有写入者的生命周期 —— 而这往往比写几行 close() 难得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
