Go 的 select 在多个 case 就绪时伪随机选择，底层哈希打乱顺序后线性扫描，旨在避免饿死和隐式顺序依赖；default 不破坏随机性，仅作为无就绪 case 时的非阻塞兜底。
select 为什么不是按 case 顺序选，而是“随机”？
Go 的 select 在多个 case 同时就绪时，并不保证按书写顺序执行，也不是轮询或优先级调度——它本质是**伪随机公平选择**。底层用的是哈希打乱 case 顺序后再线性扫描，目的是避免饿死和隐式依赖顺序的 bug。
常见错误现象：select 总走第一个 case，你以为是“默认走上面”，其实只是当前 goroutine 调度巧合；换环境、加日志、跑压测就变样。
- 这不是 bug，是设计：Go 明确不承诺顺序，文档写的是 “if multiple cases are ready, it chooses one at random”
- 别用
select实现“优先级逻辑”，比如想让ch1优先于ch2，得靠额外状态或重试机制 - 如果真要顺序尝试，改用
if ch1 != nil && len(ch1) > 0 { ... } else if ch2 != nil && len(ch2) > 0 { ... }（但注意竞态和非阻塞语义差异）
default 分支会破坏“随机性”吗？
不会破坏随机性，但会彻底改变行为模型：default 让 select 变成非阻塞——只要有任何 case 就绪就选一个；如果全没就绪，立刻执行 default。此时“随机选择”只发生在有多个就绪 case 时，default 永远是最后兜底选项。
使用场景：做非阻塞收发、心跳探测、带超时的轮询。
立即学习“go语言免费学习笔记（深入）”；
-
default和其它 case 是互斥关系：有就绪 case 就绝不会进default - 哪怕所有 channel 都空，但某个
case是 send 操作且接收方 goroutine 正在等，那这个 send 就算“就绪”，default不会触发 - 别在
default里放重试逻辑然后期望“下次 select 就能命中”，因为调度不可控，可能连续十次都进default
如何验证哪个 case 被选中了？
不能靠打印日志猜，得用可复现的受控测试。核心思路：让多个 channel 同时就绪，再观察结果分布。
实操建议：
- 用
make(chan int, 1)创建带缓冲 channel，提前写入值，确保收发操作立即就绪 - 避免用无缓冲 channel + 单独 goroutine 发送，那样依赖 goroutine 启动时机，不可控
- 写个循环跑 1000 次
select，统计各 case 命中次数，应该接近均匀（偏差在 ±5% 内属正常） - 示例片段：
ch1 := make(chan int, 1); ch2 := make(chan int, 1)<br>ch1 <- 1; ch2 <- 2<br>for i := 0; i < 1000; i++ {<br> select {<br> case <-ch1: count1++<br> case <-ch2: count2++<br> }<br>}
嵌套 select 或混用 time.After 会干扰调度吗？
不会干扰“随机选择”机制本身，但会显著增加就绪判定的复杂度。尤其是 time.After，它背后是个独立 timer goroutine，触发时间有微小抖动；加上 channel 缓冲、GC 暂停、系统调度延迟，会让“同时就绪”的条件极难稳定复现。
容易踩的坑：
-
time.After(0)并不等于“立刻就绪”，它仍需 timer 系统投递，可能比本地 channel 操作慢几个纳秒 - 把
time.After和高频率 channel 操作混在同一个select里，大概率每次都是 timer 先被选中——不是因为优先级，是因为 timer channel 更“稳定就绪”，而你的业务 channel 可能刚写完还没来得及被 runtime 扫描到 - 需要精确超时控制时，优先用
context.WithTimeout，它的取消信号走的是同步 channel，就绪更可靠
真正难处理的不是“随机”，而是你误以为它有序；最常被忽略的，是把业务逻辑耦合在 case 执行顺序上，而不是用显式状态机或重试策略来表达意图。
