关闭通道必须用 close()，不能用 defer 或赋值为 nil；只有发送方能调用且仅一次，重复关闭会 panic；关闭后仍可读取缓存数据，读完返回零值和 false；需用 v, ok :=
关闭通道必须用 close()，不能用 defer 或赋值为 nil
Go 里通道（chan）是引用类型，但关闭操作不是“置空”或“释放内存”，而是向运行时发送一个明确信号：此通道不再写入。只有发送方能调用 close()，且只能调用一次；重复关闭会 panic：panic: close of closed channel。常见错误是误以为 ch = nil 或在 defer 里无条件关——这会导致协程仍在写入时崩溃。
-
close(ch)是唯一合法的关闭方式，它不阻塞，也不影响已缓存的数据读取 - 关闭后仍可安全读取：未读完的缓存数据能继续取，读完后每次
返回零值 + <code>false - 切勿在多个 goroutine 中并发调用
close()；典型做法是让写入方（如生产者）负责关闭，读取方只读不关
select 里判断通道是否已关闭：用「逗号 ok」惯用法
读通道时无法直接感知是否已关闭，必须靠接收语法的第二个返回值。单独写 v := 会永久阻塞（若无缓存且未关闭），而 <code>v, ok := 才能区分“读到数据”和“通道已关”。这个 <code>ok 是布尔值，关闭后为 false，此时 v 是该类型的零值。
- 在循环中读通道，必须用
for v, ok := 结构，否则会漏掉最后一次读或死锁 -
select分支中同样适用：case v, ok := —— 如果 <code>ch已关闭，该分支立即触发，ok == false - 注意：即使通道关闭，
select的default分支仍可能抢占（尤其无缓冲通道），所以不能单靠default判断关闭状态
关闭时机错位：为什么消费者先关通道会 panic？
关闭通道的职责必须由写入方承担。如果消费者（读方）提前调用 close(ch)，而生产者还在往里发数据，下一次写操作就会触发 panic：panic: send on closed channel。这不是竞态检测，而是运行时强制检查——Go 不允许向已关闭通道发送任何值。
- 典型场景：worker 模式中，主 goroutine 启动多个 worker 读
jobs通道，自己负责关闭；若某个 worker 自作主张关了jobs，其他 worker 和主 goroutine 写入时全崩 - 解决方案：用额外的
done通道或sync.WaitGroup协调生命周期，确保只有最后一个写入者（或统一调度者）执行close() - 如果生产者是 for-range 遍历切片再发数据，可在循环结束后关通道；如果是网络连接流，则需监听连接断开事件后再关
带缓冲通道关闭后，len() 和 cap() 不变，但 range 会自动终止
关闭不影响通道当前长度或容量：len(ch) 仍返回剩余未读元素个数，cap(ch) 仍是原始缓冲大小。但 for-range 语义特殊：它会在读完所有缓存数据后自动退出，无需手动检查 ok。这是少数几个“隐式感知关闭”的地方。
-
for v := range ch { ... }等价于for { v, ok := - 但注意：range 只对读有效；你不能
for v := range ch { ch —— 关闭后写会 panic，且 range 不提供写能力 - 调试时别依赖
len(ch) == 0判断是否关闭；它只反映缓冲区空闲程度，与关闭状态无关
关键点就落在「谁关、何时关、怎么读」三件事上。最容易被忽略的是：关闭动作本身不传播，也不同步，它只是给读端一个“停止信号”，而写端完全不知道——所以协调责任必须靠代码逻辑显式约定，不能指望通道自己“通知对方”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
