select case 的求值顺序是随机的，Go 运行时会先对所有 case 的通信操作进行求值，再随机选择一个可执行的 case 执行，而非按代码书写顺序从上到下依次判断。
select case 的求值顺序不是从上到下
Go 的 select 语句在运行时**不会按代码书写顺序依次求值 case 表达式**，这是最常被误解的一点。每个 case 的通信操作（如 ch 或 <code>）会在进入 <code>select 时**同时准备就绪检测**，但具体哪个 case 被选中，取决于运行时的随机调度和通道状态，而非语法位置。
常见错误现象：写了一个带默认分支的 select，以为“上面的 case 不满足就走下面”，结果 default 永远不执行——其实是所有非阻塞 case 都 ready 了，运行时随机挑了一个，根本没轮到 default。
- 只有所有
case都阻塞时，default才会被立即执行 - 只要有一个
case的通道处于可读/可写状态，该case就可能被选中（无优先级保证） - 多个 ready 的
case同时存在时，Go 运行时用伪随机方式选择，不是轮询也不是栈序
为什么 runtime.selectgo 要打乱 case 顺序
源码里 runtime.selectgo 在进入主循环前，会把所有非 default case 的指针数组做一次 fastrandn 打乱。这是为了防止程序逻辑意外依赖 case 顺序，避免出现“看似稳定、实则脆弱”的竞态行为。
使用场景：当你需要公平调度多个通道（比如负载均衡式 worker 分发），这种随机性反而是优势；但如果你误以为能靠顺序控制优先级（比如“先查缓存 channel，再查 DB channel”），就会掉坑里。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 打乱发生在每次
select执行时，不是编译期固定 - Go 1.22 仍保持该行为，无配置项可关闭或切换策略
- 性能影响极小：打乱是 O(n) 数组洗牌，n 是 case 数量，通常 ≤ 10
想控制优先级？别靠写序，改用嵌套 select
真有优先级需求（比如“必须先试 A 通道，仅当 A 不可用时才走 B”），不能靠调整 case 上下位置，得靠结构控制。最稳妥的方式是拆成两层 select，用 default 做“快速失败”跳转。
示例：优先发消息到 fastCh，失败则降级到 slowCh
select {
case fastCh <- msg:
// 成功
default:
select {
case slowCh <- msg:
// 降级成功
default:
// 两个都满，丢弃或重试
}
}- 外层
select的default表示fastCh当前不可写（缓冲满或无人接收） - 内层
select同理判断slowCh，避免阻塞 - 不能用
if ch == nil或len(ch)替代——通道长度不反映可写性，且并发下立刻过期
调试时怎么确认哪个 case 被选中了
没有内置 trace 开关，但可以用最简方式加日志定位。关键是**每条 case 分支开头立刻打点**，而不是等逻辑执行完再记——因为一旦某个 case 被选中，其他 case 就不再评估了。
错误示范：select { case —— 日志在 work 后，无法区分是哪个 case 触发的。
- 正确做法：每个 case 第一行就
log.Printf("select: ch1 fired") - 更轻量：用
fmt.Print("→1 ")这类无缓冲输出，适合本地快速验证 - 注意：加日志本身会轻微改变调度节奏，高并发下可能掩盖原问题，仅用于诊断
真正难缠的是那些依赖“恰好某个 case 先 ready”的逻辑——它可能在本地跑 1000 次都正常，上线后因调度差异突然出错。这种时候，顺序不是 bug，而是设计缺陷。
