Go select 同时命中多个 case 为什么结果不固定

你在两个 channel 都已经有值时，发现同一段 select 有时走第一个 case，有时走第二个，这不是 Go 失去确定性，而是代码正好进入了语言规定的竞争场景。

如果多个通信操作在进入选择点时都能继续，Go 会从这些可继续的 case 中做一次均匀伪随机选择；case 的源码顺序不是优先级。需要固定业务顺序时，要把优先级写进额外的控制结构。

问题现场：两个 case 都 ready 时发生了什么

select 不是按上到下的 switch。接收 case 的 channel 操作、发送 case 的 channel 和待发送值，会在进入 select 时按源码顺序各求值一次。求值完成后，若有一个或多个通信可以继续，就只选择一个；没有可继续通信时才考虑 default，没有 default 则阻塞。

因此，下面两路都 ready 时，结果不由 case 排列决定：

这里的“伪随机”是规范层面的选择规则，不等于严格的轮询、绝对公平或可以预测下一次结果。业务代码应只依赖“一个可继续的通信会被选中”，不要依赖长期比例。

动手验证：最小程序为什么每次可能不同

package main

import "fmt"

func main() {
	a := make(chan string, 1)
	b := make(chan string, 1)
	a 

每次启动程序时，A 或 B 都可能被打印，但一次 select 只消费其中一个值。把两个 case 对调也不能把结果变成固定顺序。这个实验只能说明“多个 case 同时可通信时由选择规则决定”，不能用来推断某个运行时的长期公平性。

读懂三个容易混淆的边界

还要留意 case 表达式的副作用：channel 表达式和发送值会先求值，即使最后没有选中那个 case。把函数调用塞进 case 右侧，不能把它当成“只有选中后才执行”。

需要固定优先级时，先把业务规则写进结构

如果高优先级消息已经在队列里，希望本轮先处理它，可以先做一次只检查高优先级 channel 的非阻塞探测，再决定是否进入普通竞争。这个写法表达的是“探测时 high 优先”，而不是承诺整个程序永远忽略 low：

func receive(high, low 

如果需求是严格的全局优先级，单个 select 很难直接表达，还要考虑 low 已经被选中、high 在等待期间到达、消息是否允许饥饿等状态。更稳妥的做法是让一个调度 goroutine 统一收取消息，或使用显式队列和状态机。

常见问题

把 case 顺序调整一下，能不能让第一个优先？

不能。case 顺序影响表达式求值顺序，但多个通信都 ready 时的选择不是按源码顺序。要优先级就增加探测、队列或调度状态。

select 里的 default 会不会先执行？

不会。只要至少一个通信可以继续，default 就不会被选中；只有所有通信都暂时不能继续时，它才提供非阻塞分支。

测试里能不能断言一定收到 high？

只有当测试先建立了“low 不可通信”或使用了显式优先级结构时才能这样断言。两个 case 同时 ready 的普通 select 不应断言固定分支，否则测试会产生偶发失败。

排查这类问题时，先记录每个 channel 在选择点是否真的可通信，再确认代码是否把随机选择误当成业务排序。语言语义没有错，真正需要修的是未被明确表达的优先级。