Go的select中case无固定执行顺序，多个就绪case由运行时随机选择，default仅在所有channel均未就绪时立即执行。
select 的 case 没有固定优先级，运行时随机选择就绪的 case
go 的 select 语句**不保证 case 执行顺序**，哪怕某个 case 总是先就绪，也不意味着它总被选中。这是设计使然，不是 bug。底层 runtime 在发现多个 case 同时可执行时，会随机打乱遍历顺序，避免 goroutine 饥饿或隐式依赖顺序的代码。
常见错误现象：
– 本地测试时某 case 总是先触发，上线后行为突变
– 用 select 实现“默认走 A，A 不可用才走 B”，结果 B 偶尔抢在 A 前执行
- 所有
case（包括default）在每次进入select时重新评估就绪状态 -
default是唯一非阻塞分支：只要没有其他 case 就绪，它立即执行 - 如果多个 channel 操作都已就绪（例如两个带缓冲的 channel 都有数据），调度器随机 pick 一个
想让某个 case “优先”执行，必须显式控制就绪时机
真正的“优先级”得靠逻辑控制 channel 的可读/可写状态，而不是依赖 select 自身。比如想让 chA 的接收比 chB 高，不能靠写序，而要确保 chB 在 chA 确实无数据时才可能就绪。
典型做法是把高优操作提前做一次非阻塞尝试，仅当失败时才进 select：
// 想优先处理 chA，其次 chB
if val, ok := <-chA; ok {
// 成功读取，直接处理
} else {
// chA 已关闭或空，再进 select 协调 chB 和其他通道
select {
case val := <-chB:
// ...
case <-timeout:
// ...
}
}- 用
select+default做单次非阻塞探测（select { case x := <-ch: ... default: ... }） - 把高优 channel 放在独立的
select块里，只在它不可用时才 fallback 到含低优 channel 的大select - 避免在多个
case中混用同一 channel 的读/写操作——这会让就绪判断更难预测
default 分支不是“最低优先级”，而是“兜底非阻塞入口”
default 的行为常被误解。它不参与“优先级竞争”，而是在整个 select 开始时，若**所有 channel case 均未就绪**，则立刻执行。一旦任一 case 就绪，default 就完全不会运行。
-
default和其它case不是同层比较关系，它更像是“快速失败路径” - 如果所有 channel 都带缓冲且已有数据，
default永远不会执行，哪怕它写在第一行 - 在超时控制场景中，
default无法替代time.After：它不引入等待，只反映“此刻无事可做”
嵌套 select 或分阶段 select 是可控优先级的实际解法
真有强优先级需求（如：A > B > C），硬塞进一个 select 只会让逻辑混乱、行为不可控。应拆成多层控制流。
// 三级优先级：chA > chB > chC
select {
case v := <-chA:
handleA(v)
default:
select {
case v := <-chB:
handleB(v)
default:
select {
case v := <-chC:
handleC(v)
case <-time.After(100 * time.Millisecond):
// 全部不可用时的兜底
}
}
}- 每层
select只负责两级决策，语义清晰 - 外层
default触发下一层，天然形成“降级链” - 注意嵌套深度：超过 3 层容易掩盖真实阻塞点，调试困难
- 若涉及超时，把
time.After放在最内层，避免外层空转浪费 timer 资源
真正难的不是写出带优先级的 select，而是识别出哪些场景其实不该用 select —— 比如需要严格顺序响应的协议解析，用状态机 + 显式 channel 检查更稳。
