Go 的 select 默认不按书写顺序或就绪先后选择 case，而是伪随机选择，以避免 goroutine 饥饿和隐式优先级依赖；多次运行同一 select 代码，输出顺序通常不同。
select 默认分支为什么不是“最先就绪就选它”
Go 的 select 语句不保证按 case 书写顺序或 channel 就绪先后执行，而是运行时伪随机选择——这是语言规范明确要求的，目的是避免 goroutine 饥饿和隐式优先级依赖。你写 select 时不能假设第一个 case 一定先跑，哪怕它对应的 channel 已经有值。
验证方式很简单：连续运行同一段代码多次，观察输出顺序是否变化。比如：
ch1 := make(chan int, 1)
ch2 := make(chan int, 1)
ch1 <- 1
ch2 <- 2
for i := 0; i < 5; i++ {
select {
case <-ch1:
fmt.Println("ch1")
case <-ch2:
fmt.Println("ch2")
}
}实际输出可能是 ch1、ch2、ch1、ch2、ch2 这类混合序列，而非固定模式。
runtime.selectgo 是如何实现伪随机的
Go 运行时在 runtime.selectgo 中对所有就绪的 case 构建一个 slice，然后用 uintptr(unsafe.Pointer(&c)) ^ uintptr(unsafe.Pointer(&s)) 类似的地址哈希（具体是基于 case 地址和当前 goroutine ID 的简单异或+移位）生成一个索引偏移，再取模得到起始扫描位置。不是真随机，但每次调度上下文不同，结果不可预测。
立即学习“go语言免费学习笔记（深入）”；
这意味着：
- 同一段代码在不同 Go 版本、不同 GC 状态、甚至不同编译参数下，随机种子可能变化
- 即使两个 channel 同时就绪，
select也不会“轮询”或“公平调度”，只是从某个偏移开始线性扫描，选中第一个就绪项 - 没有配置项能关闭这个行为；
GODEBUG=asyncpreemptoff=1等调试变量不影响select逻辑
想控制执行顺序？别硬靠 select，换方案
如果你需要确定性行为（比如日志优先写入、超时必须先检查），select 不是工具。常见错误是反复 select + default 轮询，既浪费 CPU 又不解决问题。
更合理的做法：
- 用
if+select组合：先判断某个 channel 是否就绪（len(ch) > 0或用select { case x := 非阻塞探测），再决定是否进入 <code>select - 把高优先级逻辑拆到独立 goroutine +
time.After或context.WithDeadline控制时序 - 用带缓冲的 channel 模拟队列，配合单个
select消费，把调度逻辑移到生产端
例如，强制先处理 done 信号：
select {
case <-done:
return // 立即退出
default:
}
select {
case v := <-ch:
handle(v)
case <-time.After(timeout):
timeoutHandler()
}学习调度逻辑时最容易忽略的一点
很多人以为 select 的“随机”是为了负载均衡，其实核心目标是消除隐式依赖——一旦开发者写出依赖执行顺序的代码，就等于把调度策略耦合进了业务逻辑，而 Go 的调度器本身不承诺任何顺序保证。真正影响性能的往往不是随机本身，而是你在多个 channel 上反复 select 却没考虑唤醒延迟、goroutine 堆栈切换开销，或者误把 select 当作状态机驱动器来用。
记住：select 是并发同步原语，不是流程控制器。它的“不确定”不是缺陷，是设计使然；试图驯服它，通常说明你该重新梳理通信契约了。
