select 会阻塞，除非有 case 立刻就绪；它挂起 goroutine 直到至少一个 channel 操作可立即完成，无 default 时全阻塞，nil channel 永不就绪，多 case 同时就绪则随机执行。
select 会阻塞，除非有 case 立刻就绪
Go 的 select 不是轮询，它会挂起 goroutine，直到至少一个 case 的 channel 操作能立即完成。这意味着：如果所有 channel 都没数据、都没人接收，select 就卡住——不是“跳过”，是真等。
常见错误现象：select 看起来“不执行”、goroutine 僵死，其实是所有 case 都阻塞了，又没写 default。
- 想非阻塞尝试？必须加
default分支，哪怕只写个空语句{} - 多个
case同时就绪时，Go 随机选一个执行（不是按顺序），别依赖执行次序 -
select里不能直接写if或赋值语句，每个case只能是单个 channel 操作（、<code>ch ）或 <code>default
nil channel 在 select 中永远阻塞
把 nil channel 放进 select 的 case，那个 case 就彻底失效——既不会触发，也不会报错，只是安静地被忽略（等价于永远不可就绪）。
使用场景：常用来动态开关某个通信路径，比如初始化前先设 ch := chan int(nil)，后续条件满足再赋值为真实 channel。
立即学习“go语言免费学习笔记（深入）”；
- 调试时发现某个
case死活不走？检查它用的 channel 是不是nil - 不要在
select外对 channel 做nil判断再决定是否进select——逻辑冗余，直接放进去就行，nil会自动“静音” - 注意：关闭的 channel 不等于
nil；关闭后读操作仍可立即返回零值，所以能触发case
timeout 怎么写才不泄漏 goroutine
用 time.After 配合 select 实现超时最常见，但容易误用导致定时器泄漏——比如在循环里反复调用 time.After(1 * time.Second)，每次都会启一个新的 timer，旧的却没人关。
正确做法是每次 select 用独立的 time.Timer，用完显式 Stop()；或者更简单：只在需要时创建，且确保它只被触发一次。
- 推荐写法：
timer := time.NewTimer(1 * time.Second); defer timer.Stop()，然后case - 别用
time.After在高频循环里——它内部用time.NewTimer+defer不生效，timer 对象无法复用 - 如果 timeout 后还要重试，别复用同一个
timer，每次重试都新建一个
select 无法监听多个相同 channel 的读/写
同一个 channel 出现在多个 case 中（比如两个 case ），编译直接报错：<code>invalid operation: ch (value of type chan int) on left side of 。Go 明确禁止这种写法。
原因很实在：channel 本身已自带并发安全，重复监听同一端口没意义，还可能引发歧义（比如该让哪个 case 拿到值？）。
- 想“分流”一个 channel 的消息？用额外 goroutine + 多个下游 channel，或者用 fan-out 模式手动复制
- 想“聚合”多个 channel？老实用多个不同 channel 变量，每个单独写进
select的不同case - 注意：匿名函数捕获的 channel 变量，只要变量名不同，就算不同
case，没问题
真正难搞的不是语法，是理解 select 的调度本质——它不运行代码，只协调 channel 状态；一旦写错 channel 生命周期或忽略 nil 行为，bug 往往藏得深、复现难。
