Go select 同时就绪多个 case 时能否依赖固定顺序

不能依赖。Go 的 select 在多个通信同时可执行时，会从这些可执行的 case 中选择一个，而不是按照源码从上到下固定命中。规范把这个选择定义为“均匀伪随机”，所以把高优先级 channel 写在前面，只能影响阅读，不会形成调度优先级。

一、先确认 select 的选择规则

把两个带缓冲 channel 都预先写入数据，循环中同时接收它们。每次循环结束后重新填充，观察结果可能交替，也可能连续命中同一个 channel。这个现象不是 Go 承诺的轮询顺序，而是随机选择的正常表现。

package main

import "fmt"

func main() {
	left := make(chan string, 1)
	right := make(chan string, 1)

	for i := 0; i 

运行多次后输出顺序可能不同。即便某次连续选中 left，也不能据此推断下一次仍会选它；随机结果只有在大量样本中才适合做统计观察，不能当作业务协议。

二、求值顺序不等于 case 顺序

这里最容易混淆的是两个“顺序”。进入 select 时，所有 case 中的 channel 操作数，以及发送 case 的右值，会按照源码顺序各求值一次；但求值完成后，运行时会从能够继续的通信里选一个。因此，下面的日志可能先打印 left channel，却最终执行右侧接收分支。

package main

import "fmt"

func channel(name string, ch 

所以，不能用副作用函数的调用顺序推导 case 的执行顺序。更稳妥的写法是让 channel 表达式保持简单，把日志、计数和业务动作放到实际选中的 case 内。

三、为什么不能把随机选择当成公平调度

“均匀伪随机”表示候选 case 会被随机选取，并不表示每个业务对象在任何短窗口内严格轮流，也不保证高优先级消息永远先处理。下面这张判断表可以帮助排除几种常见误用。

四、需要优先级时怎么写

如果只是希望“有高优先级消息时尽量先拿”，可以先用一个带 default 的小 select 探测高优先级 channel，再进入包含普通 channel 的 select。注意这仍然不是严格保证：高优先级消息可能在探测之后才到达，第二个 select 也可能已经同时看见两个就绪 case。

func consume(high, normal 

若系统要求严格优先级，不要继续调整 case 排列。可以让一个 dispatcher 负责接收输入，把消息分别放入高、普通两个内部队列，再由单一决策点始终先取高优先级队列。这样“谁先处理”由数据结构和调度代码表达，测试也更容易稳定。

相关问题

select 没有 case 会怎样？

select {} 会永久阻塞当前 goroutine。只有 nil channel 的 select 且没有 default，也会一直阻塞。

加上 default 就能保证先处理高优先级吗？

不能。两阶段写法只能降低普通消息抢先的概率，不能覆盖探测之后到达的消息和第二阶段的随机选择。

如何测试 select 的分支逻辑？

不要断言某一次一定命中某个 case；分别测试每个 channel 单独就绪、都就绪和都未就绪的行为，并让处理函数可观察、可重复。