nil channel 在 select 中被跳过而非阻塞；其行为是 go 明确定义的语义，可用于安全开关分支，但需确保无 goroutine 正在收发且解引用指针前判空。
nil channel 在 select 中永远阻塞
当 select 的某个 case 使用的是 nil channel 时，Go 运行时会直接跳过该分支，相当于“禁用”——它既不会触发，也不会报错，更不会导致死锁（只要其他分支可执行）。这是 Go runtime 对 nil channel 的明确定义行为，不是 hack，是可依赖的语义。
常见错误现象：有人把 channel 变量初始化为 nil 后直接 select，发现程序卡住，其实是其他分支也阻塞了，误以为是 nil 导致的；真正该检查的是：是否所有非 nil 分支都不可就绪。
- 只对明确需要动态开关的分支设为
nil，别一上来全设nil然后等“唤醒” - 赋值为
nil前确保没有 goroutine 正在向它发送或接收（否则 panic） -
nilchannel 的len()和cap()都 panic，不能取长度
用指针或接口控制 channel 生命周期
想让某个 case “按需启用”，最稳妥的方式不是反复赋值 nil/make(chan...)，而是用一个指针或接口变量间接引用 channel。这样可以在不改变 select 结构的前提下，安全切换背后的 channel 实例。
使用场景：比如一个服务要支持热启停某类事件监听，又不想重启 goroutine 或加锁判断开关状态。
立即学习“go语言免费学习笔记（深入）”；
- 声明
var ch *chan int，然后用*ch参与select - 启用时：
c := make(chan int, 1); ch = &c；禁用时：ch = nil - 注意：
ch本身是nil指针时，*ch会 panic，所以得确保ch != nil才解引用 - 更推荐用
interface{}包一层，或直接用chan int类型变量 + 显式判空
select 中混用 nil 和非 nil channel 的实际写法
真实代码里，你不会看到裸写的 case （语法错误），而是通过变量间接实现。关键在于：channel 变量值为 <code>nil 时，整个 case 被忽略。
示例中容易踩的坑：把 nil 当成“空 channel”，试图从它读取默认值，或者误以为 default 会兜底所有 nil 分支——其实 default 只在所有非 nil 分支都阻塞时才执行。
- 正确写法：
case ，其中 <code>someChan是一个可能为nil的变量 - 错误写法：
case ，编译失败；也不能用类型转换绕过 - 性能无损耗：runtime 对
nilchannel 的判断是常量时间，不涉及调度器介入
禁用后重新启用 channel 的时机和同步问题
channel 从 nil 切回有效值，本身不带同步语义。如果多个 goroutine 并发读写这个 channel 变量，必须加锁或用 atomic.Value，否则存在竞态。
典型兼容性影响：Go 1.0 就支持该行为，所有版本一致；但如果你在 select 外部做了 close(ch)，再把它设为 nil，后续重启用的新 channel 不受影响——旧的已关闭状态不会“传染”。
- 不要在
select正在运行时修改 channel 变量，尤其不能一边select一边close()它 - 启用新 channel 前，确保老 channel 上所有 pending send/receive 已完成或被放弃
- 最简单的同步方式：用
sync.Once控制启用逻辑，或把 channel 变量封装进 struct 加 mutex
真正难的不是设 nil，而是厘清哪些 goroutine 持有旧 channel 引用、谁负责清理、何时才算“彻底下线”。这些边界不画清楚，nil 只会让问题更隐蔽。
