只读 channel 不能被关闭，编译器禁止对 <-chan T 调用 close()；关闭权仅属发送方，接收方应通过 v, ok := <-ch 判断关闭状态，或使用 context.Context 替代。
只读 channel 不能被关闭，close() 会编译报错
Go 的类型系统在编译期就禁止对只读 channel（chan<- T）调用 close()。这不是运行时限制，而是语言设计强制的约束：只读意味着“你只负责收”，关不关、何时关，必须由发送方（即拥有 <-chan T 对应的双向或只写 channel 的那一端）决定。
常见错误现象：invalid operation: close(ch) (cannot close receive-only channel)
- 如果你拿到的是函数参数
ch <-chan int，别试图关它——你没权限，编译器直接拦住 - 真正该关 channel 的，是那个创建它、并保留了
chan int或chan<- int类型变量的地方 - 如果函数需要“通知接收方停止”，应由调用方传入一个单独的
done <-chan struct{}，而非让接收方关 channel
关闭 channel 的唯一安全时机：所有发送者都已退出
channel 关闭的本质是「信号」：告诉所有当前和未来的接收者，“不会再有新值了”。一旦关闭，再向它发送数据会 panic：panic: send on closed channel；而接收操作会立即返回零值 + false。
使用场景：多 goroutine 并发写入同一 channel，主 goroutine 等待全部写完后关闭
立即学习“go语言免费学习笔记（深入）”；
- 多个 sender？必须用 sync.WaitGroup 或其他同步机制确保它们全部退出后再
close(ch) - sender 和 receiver 是 1:N 关系？关闭动作仍只能由 sender 侧统一协调，receiver 绝不参与关闭逻辑
- 不要在 defer 中无条件
close(ch)—— 如果 ch 是参数传入且可能已被关，会 panic
接收端如何正确判断 channel 是否关闭
仅靠 <-ch 取值是不够的，必须用双赋值语法捕获第二返回值（ok），否则无法区分「收到零值」和「channel 已关闭」。
常见错误现象：int channel 发送了 0，接收端却误判为已关闭
- 正确写法：
v, ok := <-ch；ok == false才代表 channel 已关闭且无更多数据 - for-range 隐含了这个判断，所以
for v := range ch在关闭后自动退出，但要注意：range 不感知中间关闭，只在下一次尝试接收时退出 - 如果接收逻辑中混用了
<-ch和for range ch，容易漏掉最后几个值或重复处理
替代方案比强行关只读 channel 更可靠
当你发现自己“想关一个只读 channel”，大概率是接口设计出了问题。Go 鼓励用组合而非控制来表达协作语义。
典型替代方式：
- 用
context.Context控制生命周期：ctx.Done()通知接收方主动退出，比关 channel 更灵活 - 把 channel 和关闭逻辑封装进结构体，暴露
Close()方法，内部管理底层双向 channel 的状态 - 如果只是想“停止接收”，直接 return 或 break 即可，不必依赖 channel 关闭 —— 尤其在 select 中配合
default或ctx.Done()
最容易被忽略的一点：channel 关闭是全局广播，所有正在阻塞在 <-ch 上的 goroutine 都会同时被唤醒。如果没做好并发控制，可能引发竞态或重复处理。别把它当线程信号量用。
