能，channel关闭后仍可读，但仅返回零值；需用val, ok :=
channel 关闭后还能读吗？能，但要靠 ok 判断
能读，但不是“读到新数据”，而是读完缓存后持续返回零值——除非你用带 ok 的双值接收。这是 Go channel 最容易误判的点：很多人以为关闭后 val := 会 panic 或阻塞，其实它安静地吐零值，直到永远。
常见错误现象：for val := range ch 正常退出，但手写 for { val := 却陷入无限循环，<code>val 一直是 0（int）、""（string）、nil（指针）等零值，毫无提示。
- 必须用
val, ok := 形式，<code>ok为false才表示 channel 已关且无剩余数据 -
range语法内部自动做了ok检查，所以安全；裸接收不检查，等于主动放弃状态感知 - 关闭后对已缓冲 channel 的读取，仍按 FIFO 返回缓存值，读完才开始返回零值 +
ok=false
零值和 ok=false 不是一回事，别混用
零值是类型默认值，ok=false 是 channel 关闭信号——两者可能同时出现，但语义完全不同。拿 chan int 举例：0 可能是合法业务数据，也可能是 channel 关闭后的占位符，仅靠值无法区分。
使用场景：当 channel 传输的是可能为零的类型（如 int、bool、struct{}），或需要明确区分“没数据”和“数据就是零”时，ok 是唯一可靠依据。
立即学习“go语言免费学习笔记（深入）”；
if val := ❌ 无法判断是业务零值还是关闭信号if val, ok := ✅ 唯一正确关闭检测方式- 关闭空
chan struct{}后，立即返回 <code>struct{}{}, false，此时零值与关闭强绑定，但仍是靠ok驱动逻辑，不是靠结构体本身
关闭已关闭的 channel 会 panic：panic: close of closed channel
Go 运行时严格禁止重复关闭，这和 mutex 解锁、文件关闭等行为一致——关闭动作本身是不可逆的“终态操作”。但问题在于：谁该关？什么时候关？怎么避免多 goroutine 竞争关闭？
常见错误现象：多个 goroutine 都认为自己负责清理，结果一个先关，另一个再关就直接崩溃；或者 sender 和 receiver 都试图关同一 channel，尤其在 select + timeout 场景下极易触发。
- 原则：**只有 sender（写端）可以关闭 channel**；receiver（读端）关是错的，编译器不拦，但运行时 panic
- 如果 sender 有多个 goroutine，需用 sync.Once 或额外 channel 协调，确保仅一次关闭
- 不要在 defer 中无条件
close(ch)，除非你能 100% 确保该 goroutine 是唯一 sender 且不会被重复启动
从 nil channel 读写会永久阻塞，但关闭 nil channel 会 panic
nil channel 不是“空 channel”，它是未初始化的指针，所有操作都进不了 runtime 的队列处理逻辑。这点和 map、slice 的 nil 行为不同——map/slice 的 nil 读是安全的（返回零值），但 channel 的 nil 读/写直接卡死。
性能影响：阻塞在 nil channel 上的 goroutine 永远不会被唤醒，造成 goroutine 泄漏；而 panic 是立即可见的失败，反而更容易定位。
var ch chan int; → 永久阻塞，GC 不回收该 goroutine-
var ch chan int; close(ch)→panic: close of nil channel - 典型坑：函数参数传入
chan int，没做非空校验就直接close(ch)，上游传了nil就崩
