nil通道在select中永远不就绪，被静默跳过而非阻塞；这是Go明确定义的语义，可用于动态禁用分支，但需确保无goroutine正在收发且赋值前判空。
nil 通道在 select 中不会阻塞，而是永远“就绪”，但直接用它退出循环极易引发 CPU 空转或逻辑错乱——这不是 bug，是设计使然，关键在于怎么用。
为什么 nil 通道在 select 里总被选中？
Go 规范明确：对 nil 通道的发送或接收操作会永久阻塞；但在 select 中，nil 通道被视为“永远不可通信”，因此对应 case 永远不就绪——等等，这和直觉相反？其实不是。准确地说：select 对 nil 通道的处理是：该 case 永远不满足（即永远不会执行），而非“永远就绪”。但初学者常误把“case 不执行”当成“可用来判断关闭”，结果把已关闭通道设为 nil 后，漏掉其他非 nil 通道的读取机会。
常见错误写法：
default
- 接收时用
v, ok := 判断是否关闭，关闭后立即将该 channel 设为 <code>nil - 所有 channel 都为
nil时，说明全部关闭完毕，可安全break - 绝不把退出逻辑放在
default分支里——它只适合做非阻塞探针，不适合做主退出路径
正确示例：
for
- 已关闭的通道在
select中仍持续就绪，每次都会触发对应 case，即使你只读一次，后续迭代仍会反复进入该分支 - 若未及时将 channel 置
nil，就会不断从已关闭通道读出zero value, false，容易误写入数据或忽略真实退出信号 - 标志位需额外同步，而
nil是值语义，天然线程安全（前提是 channel 变量本身不被并发写）
更糟的是，有人把标志位重置写在循环开头，导致状态无法累积——比如 ch1Closed = false 每轮都清零，永远达不到 ch1Closed && ch2Closed 的退出条件。
nil 通道 + range 更简洁？不总是
range 在单通道场景下确实干净：for v := range ch 自动处理关闭；但面对多个 channel，range 无能为力——它不支持多路复用。
所以实际工程中：
- 单一 producer → 单一 consumer：优先用
range - 多 producer / 多 channel 聚合消费：必须用
select+nil控制 - 若通道数量动态（如切片存 channel），可用反射或生成代码，但通常先固定数量、再抽象为函数
最易被忽略的一点：nil 操作本身不 panic，但向 nil channel 发送会 panic；所以只对已知只读的 channel 置 nil，发送方 channel 应由生产者 close，消费者只负责接收后判空并置 nil。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
