select语句不保证case执行顺序，多个可执行case会伪随机选择，旨在避免竞态；常见错误是误将本地稳定现象当作优先级，导致上线后逻辑异常。
select 语句没有固定执行优先级
Go 的 select 语句本身不保证 case 的执行顺序，也不会按书写顺序、通道就绪先后或 channel 类型（buffered/unbuffered）自动排序。只要多个 case 同时可执行（比如多个 channel 都有数据可读、或都可写），运行时会**伪随机选择一个**，这是 Go 运行时的明确设计，目的是避免隐式依赖导致的竞态和难以复现的问题。
常见错误现象：
– 在本地反复测试时总看到某个 case 先执行，误以为“它优先”；
– 上线后行为突变，比如超时逻辑没触发、日志漏发、goroutine 意外阻塞。
- 不要依赖书写顺序（
case ch1 写在前面 ≠ 更可能被选中） - 不要依赖 channel 是否带缓冲（
chan int和chan int缓冲大小为 1，在 select 中地位完全平等） - 如果需要确定性行为，必须显式控制——比如用
default做兜底，或拆成多个独立select
default 分支会破坏“阻塞等待”语义
有 default 的 select 不会阻塞，它会立即检查所有 channel 状态：任一可执行就走对应 case；全不可执行就走 default。这常被用来做非阻塞通信或轮询，但容易忽略其对逻辑节奏的影响。
使用场景举例：
– 心跳检测中避免 goroutine 卡死
– 尝试发送但不想等接收方就绪
立即学习“go语言免费学习笔记（深入）”；
-
default不是“最低优先级分支”，而是“无可用 channel 时的 fallback” - 加了
default后，即使所有 channel 都 ready，也仍可能因伪随机机制跳进default（极小概率，但存在） - 若想确保只在 channel 真正不可用时才执行 fallback，应改用带超时的
select+time.After
多个就绪 channel 下的伪随机选择实际怎么发生
Go 运行时在每次进入 select 时，会将所有 case（不含 default）打乱顺序，再线性扫描，取第一个可执行的。这意味着：即使你反复运行同一段代码，只要调度时机或内存布局稍有变化，选中的 case 就可能不同。
ch1 := make(chan int, 1)
ch2 := make(chan int, 1)
ch1 <- 1
ch2 <- 2
<p>select {
case v := <-ch1:
fmt.Println("from ch1:", v)
case v := <-ch2:
fmt.Println("from ch2:", v)
}上面代码每次运行输出都可能是 from ch1: 1 或 from ch2: 2，且无法预测。这不是 bug，是语言规范要求的行为。
- 该随机性由运行时内部的
selectgo函数实现，不暴露给用户，也不受rand.Seed影响 - 性能上无明显差异：打乱成本极低，扫描是 O(n)，n 是 case 数量，通常很小
- 跨平台行为一致：Linux/macOS/Windows 下表现相同
需要确定性时的替代方案
当业务逻辑确实要求“先处理 A，A 不可用再处理 B”，就不能靠 select 的随机性，而要主动构造顺序控制流。
- 用两次独立
select：第一次只含 A 相关 case + 超时，失败后再跑含 B 的 select - 用
if select { ... } else { ... }模式，配合default判断 A 是否就绪 - 更清晰的做法是放弃
select，直接用ch1 == nil或len(ch1)（仅限 buffered channel）做前置判断（注意：这不是并发安全的通用解法，仅适用于特定可控场景）
真正难的不是写出让某个 case “优先”的代码，而是意识到：一旦引入多个并发通道，所谓“优先”往往暴露的是设计缺陷——比如本该串行的逻辑被错误并行化，或缺少状态协调机制。
