Go 运行时在 runtime.selectgo 中随机选择就绪 case：先收集所有就绪 scase，再以 goroutine 地址和单调时钟为 seed 哈希打乱索引，最后线性扫描取首个。
select 多个 case 就绪时，底层怎么选中一个
go 运行时在 runtime.selectgo 函数中实现选择逻辑：它先收集所有就绪的 scase（每个 case 对应一个 scase 结构），然后对这些就绪项的索引做哈希打乱（使用当前 goroutine 的地址和系统单调时钟做 seed），最后线性扫描打乱后的顺序，取第一个。这个过程每次 select 执行都重新发生，不是固定轮询，也不是按源码顺序。
关键点：
- “就绪”是运行时判定的：比如
ch 是否就绪，取决于 channel 是否有缓冲且未满；<code> 是否就绪，取决于是否有值可读或 channel 已关闭 - 打乱只作用于「已就绪」的 case 列表，没就绪的 case 根本不参与
- 没有全局随机数生成器，seed 来自 goroutine 本地状态，所以同一段代码在不同 goroutine 中行为可能不同
为什么你总看到 select 走第一个 case
这不是随机失效，而是你没让多个 case 真正同时就绪。常见原因：
- 用无缓冲 channel，但发送方 goroutine 启动/执行有延迟，导致只有一个
case实际就绪 - 某个
case是 send 操作，而接收方还没调用，该 send 就不算就绪 - 加了
fmt.Println或time.Sleep，改变了调度节奏，把“接近就绪”变成“有先后” - channel 已关闭：关闭后
立即就绪（返回零值 + <code>ok=false），但容易被误判为“一直可读”
验证方法：用 make(chan int, 1) 预填值，确保收发都立即就绪，再循环 1000 次统计分布——结果应在 ±5% 均匀范围内。
default 分支会影响随机选择吗
不会影响「多个就绪 case 之间如何选」，但会彻底改变行为模型：
立即学习“go语言免费学习笔记（深入）”；
-
default让整个select变成非阻塞：只要有任何 case 就绪，就从就绪集中随机挑一个；全不就绪才进default -
default不参与随机选择，它只是兜底，优先级最低（仅当无就绪时触发） - 即使所有 channel 都空，但某个 send case 的接收方 goroutine 正在等，该 send 就算就绪，
default不会执行 - 别在
default里写time.Sleep(1 * time.Millisecond)然后重试，下一次就绪状态可能完全不同，无法形成稳定重试节奏
别依赖 select 实现业务优先级
想让 ch1 优先于 ch2？直接写 select 无效。因为：
- 写在前面 ≠ 优先执行；运行时可能每次都选
ch2 - 伪随机打乱后，顺序完全不可控，也不该被测试或文档化
- 真正需要优先级时，得用显式控制：比如先检查
len(ch1) > 0再尝试非阻塞接收，失败再查ch2 - 注意：这种手动检查和
select语义不同——它不阻塞、不注册等待队列、不触发 goroutine 唤醒，需自行处理竞态
最易被忽略的是：“随机性”只在多个 case 同时就绪时生效；而“就绪”的判定本身高度依赖缓冲区长度、goroutine 调度时机、channel 是否关闭——这些才是实际编码中必须反复验证的细节。
