必须由发送方关闭且仅一次；接收方关、多发送方竞相关、defer无条件关均易panic；for range ch退出需channel已关且缓冲数据读完，缺一不可。
必须由发送方关闭，且只能关一次；接收方关、多发送方竞相关、defer无条件关——这三类操作八成会 panic。
谁有资格调用 close()
只有明确知道自己是最后一个可能往 channel 写数据的 goroutine，才有资格调用 close()。编译器不检查逻辑，但运行时会立刻报错：panic: close of closed channel 或更危险的 panic: send on closed channel。
- 接收方调用
close()：编译可能放过（比如通过interface{}传入），但运行必 panic ——close of receive-only channel - 多个发送方各自判断“我写完了”就关：典型竞态，谁先关完，后一个关就 panic
- 主 goroutine 启动 N 个 worker 往同一
chan int写，却没设终结者：没人该关，也没人敢关
for range ch 退出的前提很苛刻
for v := range ch 看似自动退出很省心，但它只在两个条件同时满足时才停：channel 已关闭 且 缓冲区中所有数据已被读完。漏掉任一条件，就会卡死或泄漏。
- 常见错误：启动 goroutine 发送
ch ，紧接着 <code>close(ch)—— 若ch是无缓冲的，发送 goroutine 永远阻塞在 `range 却已退出，造成 goroutine 泄漏 - 有缓冲也不保险：若
cap(ch) == 10，你发了 8 个就close()，range能读完 8 个后退出；但若第 9 个还在发送途中，就可能 panic - 安全做法：用
sync.WaitGroup等所有发送 goroutine 显式 return 后，再close()；或改用select监听主动退出
检测 channel 是否关闭？别试了
Go 标准库没有线程安全、无副作用的函数能告诉你 channel 是否已关闭。网上流传的 select { case 技巧，本质是试探“此刻能否非阻塞接收”，它无法区分“channel 空了”和“channel 关了”。
v, ok := 中 <code>ok == false只在 channel 关闭 且 缓冲为空时才成立；若缓冲还有数据，ok仍为true，你读到的可能是合法零值（比如发了个0）- 用
len(ch)或cap(ch)判断？完全无效 —— 它们只反映缓冲区状态，与关闭标志位无关 - 真正可靠的信号不是“channel 关了”，而是“我该停了”：用
context.Context控制生命周期，比依赖close()更正交、更可控
最易被忽略的一点：关闭 channel 不等于释放资源。它只是发了个“数据结束”信号；goroutine 是否退出、内存是否回收，全看你有没有同步机制配合。单靠 close()，解决不了任何竞态或泄漏问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
