Go的select在多个case同时就绪时伪随机选择，底层通过哈希打乱索引后线性扫描实现公平调度，旨在避免饥饿和隐式顺序依赖；default仅兜底，不参与随机选择。
go 的
在多个
同时就绪时，确实会伪随机选择一个执行——这不是巧合，而是运行时明确实现的公平调度策略。
底层怎么做到“随机”的
它不按代码书写顺序扫描，也不轮询，更不是优先选第一个；而是把所有就绪的
索引打乱（用哈希 + 位运算做伪随机重排），再线性遍历选第一个。这个过程在每次
执行时都重新发生。
目的是防止 goroutine 饥饿：避免某个
总是被跳过
消除隐式顺序依赖：如果靠写法顺序决定行为，改个
位置就可能破坏逻辑
不可预测 ≠ 不可控：只要控制好哪些
就绪，就能控制行为边界
为什么你常看到“总走第一个 case”
那不是
按顺序选，而是你没让多个
真正同时就绪。常见诱因：
用无缓冲 channel，但发送方 goroutine 启动/执行时机不确定，导致只有一个
实际就绪
某个
是 send 操作，而接收方还没 ready，该
就不算就绪
加了日志或调试语句，改变了 goroutine 调度节奏，让原本接近同时的就绪变成有先后
验证方法：用
预填值，确保收发都立即就绪，再跑 1000 次循环统计分布——结果会接近均匀（±5% 内）。
default 分支不会干扰随机性，但会改变行为模型
的作用是兜底，不是参与随机选择。它的存在让整个
变成非阻塞，但不影响“多个就绪
间如何选”这一层逻辑：
只要有任意一个
就绪（哪怕只有一个），
就完全不执行
只有所有
都不就绪时，才进
别在
里放“重试逻辑”并指望下次命中特定
——因为下一次就绪状态可能完全不同
别用 select 实现优先级，除非你清楚代价
想让
优先于
？直接写
不行。常见误操作：
把
放第一个
，以为能“优先”——实际无效，且误导维护者
在
里 sleep 后重试——增加延迟、浪费资源、仍不保证顺序
真要优先级，得用显式状态控制，比如：
，但注意这和
的阻塞/非阻塞语义不同，且需自行处理竞态。
最易被忽略的一点：随机性只在“多个就绪”时生效；而“就绪”的判定本身依赖 channel 缓冲、goroutine 调度、是否关闭等细节——这些才是实际编码中真正需要反复验证的部分。
selectcasecaseselectcasecasecaseselectcasecasecasecasemake(chan int, 1)defaultselectcasecasedefaultcasedefaultdefaultcasech1ch2selectch1casedefaultif ch1 != nil && len(ch1) > 0 { ... } else if ch2 != nil && len(ch2) > 0 { ... }select