空 select{} 会导致 goroutine 永久休眠，引发死锁崩溃；正确做法是配合信号通道或 sync.WaitGroup 实现阻塞等待。
select 必须有至少一个可通信的 case，否则直接 panic
空 select{} 不是“什么都不做”，而是让当前 goroutine 永久休眠；运行时检测到所有 goroutine 都在等，就会报 fatal error: all goroutines are asleep - deadlock!。这不是延迟问题，是编译期放行、运行期崩溃的典型陷阱。
- 错误写法：
select{}—— 即使你只是想“卡住主协程等子协程结束”，也得配个信号通道或用sync.WaitGroup - 正确做法：若真要阻塞等待，用
select { case ，其中 <code>done是关闭的通道或由其他 goroutine 关闭 - 想轮询又不阻塞？加
default分支，但注意它每次都会立即执行，别忘了配time.Sleep防止 CPU 空转
多个 channel 同时就绪时，select 不按代码顺序选，也不按发送先后选
哪怕 ch1 先发数据、ch2 后发，只要在 select 开始判断那一刻两个都已就绪，Go 运行时就随机挑一个执行——不是伪随机，是真正非确定性的调度行为。这设计是为了防饥饿，但也意味着你不能靠书写顺序控制逻辑优先级。
- 常见误判：把
写在最后，以为“超时/取消就低优先级”，其实没用；必须拆成嵌套 <code>select或用if提前判断 - 正确姿势：高优先级逻辑（如退出信号）单独拎出来先 check，再进主
select处理业务通道 - 调试时反复跑几次，看输出是否跳变，就能验证是不是被随机调度了
case 中的函数调用会在 select 判定时立刻执行，可能卡死整个语句
select 不是“等到某个 case 触发再执行右边表达式”，而是所有 case 右边的表达式（包括函数调用、time.After() 构造等）在进入 select 的瞬间就求值完毕。如果里面藏着 http.Get 或 time.Sleep(5 * time.Second)，整个 goroutine 就卡在这儿不动了。
- 错误示例：
case —— 查询完才进 <code>select，根本没起到超时作用 - 正确写法：先把耗时计算挪到
select外，比如timeout := calculateTimeout()，再写case - 特别注意
make(chan int, 0)和make(chan int, 1)对“就绪”判断的影响：缓冲为 1 的 channel 在有空间时接收操作就直接就绪，可能让你误以为数据“早到了”
用单 channel + type switch 替代多 channel select，更适合消息路由场景
当你要处理多种消息类型（比如 TextMessage、CommandMessage、AlertMessage），硬拆成 textCh、cmdCh、alertCh 再用 select 监听，看似“很 Go”，实则埋坑：消息乱序、类型丢失、goroutine 调度开销大、新增类型要改多处。
立即学习“go语言免费学习笔记（深入）”；
- 推荐方案：统一走
chan Message，其中Message是接口，各消息类型实现它；处理器里用switch m := msg.(type)分发 - 好处是顺序严格、类型安全、扩展成本低；坏处是你得自己保证上游只发合法类型，否则
default分支会 panic - 多 channel 方案只在真正需要“竞争式响应”时才合理，比如“谁先返回结果谁赢”的合并查询，而不是日常的消息分发
Go 的 select 表面简单，但每个 case 的求值时机、就绪判定逻辑、nil channel 行为、default 分支语义，全都在暗处咬人。最容易被忽略的，其实是“函数调用提前执行”和“随机选择不可依赖”这两点——它们不会报错，只会让程序在压测或特定时间点突然表现异常。
