range能自动退出是因为关闭channel时运行时置closed标志并唤醒阻塞goroutine，range底层调用chanrecv检测到closed且缓冲为空即返回false终止循环；非广播机制，而是状态检查与被动感知协同完成。
channel 关闭后，为什么 range 能自动退出？
因为 Go 运行时在关闭 channel 时会唤醒所有阻塞在 recv 和 send 上的 goroutine，并统一标记该 channel 已关闭。对 range ch 来说，底层等价于持续调用 chanrecv，当它检测到 closed 标志且缓冲区为空时，就返回 false 并终止循环。
关键点在于：不是靠“广播”通知每个 goroutine，而是靠唤醒 + 状态检查完成的协同退出。没有消息推送，只有状态变更和被动感知。
-
close(ch)最终调用closechan（位于runtime/chan.go） -
closechan先置c.closed = 1，再遍历c.recvq和c.sendq唤醒所有 g - 被唤醒的 goroutine 在
chanrecv或chansend中检查c.closed，决定是否 panic 或返回
select 中读取已关闭 channel 不会阻塞，但为什么有时还 panic？
读取已关闭 channel 的行为分两种：带 ok 的接收（v, ok := ）返回零值 + <code>false；不带 ok 的接收（v := ）在 channel 关闭且缓冲为空时直接 panic。
这是因为 chanrecv 函数内部有明确分支：
if c.closed == 0 {
// 正常流程
} else {
if c.qcount == 0 {
// 缓冲为空 → 返回零值，ok=false（带 ok 情况）
// 或者直接 goto panic（不带 ok、且非 select 场景）
}
}
- 在
select语句中，即使 channel 已关闭，只要它出现在某个case分支，运行时仍会把它当作可就绪分支处理（即“就绪”不等于“有数据”） - 但普通语句
没有就绪判断逻辑，直接走 recv 路径，遇到关闭+空缓冲就 panic - 所以
select是安全的，裸读不是
为什么不能多次关闭同一个 channel？
因为 closechan 开头就有显式检查：if c.closed != 0 { panic("close of closed channel") }。
这个检查不是靠锁或原子操作保护的竞态，而是靠单次写入语义保证：一旦 c.closed 被设为 1，后续任何 close 都会命中该 panic。
- 关闭动作本身是原子的（
*c.closed = 1），但检查发生在写入前 - 多个 goroutine 同时 close 同一个 channel 会导致至少一个 panic，Go 不保证哪个成功
- 因此业务层必须自行确保只 close 一次，运行时不会帮你做去重
关闭 channel 后，发送端还能继续往里 send 吗？
不能。只要 channel 关闭，任何 ch 都会立即 panic，无论缓冲是否还有空间。
因为 chansend 在进入主逻辑前就检查 c.closed，如果为真，直接 goto panic，根本不看 c.qcount 或 c.buf。
- 这和接收不同：接收还能从缓冲区“捞出最后几条”，发送则彻底禁止
- 关闭意味着“数据流终结”，发送权被立即收回
- 哪怕你刚 close，另一个 goroutine 还在执行
ch ，也会 panic，不存在“窗口期”
真正容易被忽略的是：关闭 channel 的责任归属。运行时不管谁关的，只管关了之后的行为一致性。但若多个 goroutine 都认为自己该关，又没协调好，panic 就成了常态。
