关闭channel是原子操作，调用后立即进入已关闭状态：写必panic，读必成功或返回零值+false；不存在“半开半闭”状态，也无安全窗口。
关闭瞬间的读写没有“安全窗口”——它不是竞态问题，而是确定性行为：写必 panic，读必成功或返回零值+false。
关闭 channel 的那一刻，close(ch) 是原子操作
Go 运行时对 close() 的实现是原子的，不存“半开半闭”状态。调用返回后，channel 立即进入已关闭状态。所有后续写入（无论是否在同 goroutine）都会触发 panic: send on closed channel；所有后续读取则按规则响应：有缓存数据就读数据+ok==true，否则读零值+ok==false。
常见错误现象：
- 以为“刚 close 完还没来得及传播”，在 close 后立刻
ch 尝试“抢最后一发”——结果 100% panic - 在多 goroutine 场景下，用
if !closed标志位 +close(ch)组合，误以为能避免重复 close——实际仍可能因判断与执行之间被抢占而 double close
实操建议：
- 永远不要依赖“时间差”做读写判断；
close()后禁止任何发送逻辑 - 用
sync.Once包裹close(ch)，而不是靠条件判断 - 无缓冲 channel 在
close()后立即对任何返回零值+<code>false；有缓冲的则先清空缓冲再切换
select 中读已关闭 channel 的行为是确定的，但容易漏掉 ok
当 select 的某个 case 对应的 channel 已关闭，该 case 会**立即就绪**（不会阻塞），并执行接收操作。但若只写 case v := ，你将无法区分“读到零值”和“channel 已关”，因为 int 类型的零值 0 和关闭后读出的 0 完全一致。
常见错误现象：
- worker goroutine 在
select中监听多个 channel，其中一个关闭后持续触发该 case，导致无限循环处理 0 值 - 把
case 和 <code>case msg := 并列，却没检查 <code>ch是否已关，结果把关闭信号当成有效消息
实操建议：
- 所有可能关闭的 channel，在
select的接收分支中必须使用双值形式：case msg, ok := - 收到
!ok应立即退出循环或跳过后续处理，不能继续用msg - 不要在同一个
select中混用“控制通道”（如done）和“数据通道”（如ch）而不做状态隔离
用 for range ch 遍历时，关闭只影响下一次迭代
for range ch 是语法糖，等价于持续执行 v, ok := 并在 <code>!ok 时自动 break。但它**不感知“中途关闭”**：如果当前迭代已从 channel 取出一个值（ok==true），此时发送方调用 close(ch)，本次循环体仍会执行；下一次迭代才检测到关闭并退出。
常见错误现象：
- 误以为
range能“实时响应”关闭，从而在循环体内省略对v的有效性校验，导致处理了本不该出现的零值 - 在循环体中启动新 goroutine 处理
v，而主 goroutine 已 close channel，子 goroutine 却还在用旧值做耗时操作，造成逻辑错位
实操建议：
-
for range适合简单消费场景；若需在每次读取后立即响应关闭（比如清理资源），改用显式for { v, ok := - 若循环体内有异步操作，应把
v值拷贝进去，避免引用被后续关闭影响 - 不要在
range循环中调用close(ch)—— 这是发送方职责，且range本身不提供关闭能力
真正难的不是测出“关闭瞬间”的行为，而是接受 Go 的设计前提：channel 关闭不是同步信号，而是写入终止的声明。它不保证接收方立刻得知，也不允许接收方干预生命周期。所有“深度测试”最终都指向同一个实践约束：别猜状态，用 + <code>ok 每次读都验证，比任何反射、计时、轮询都可靠。
