Go select 多个 case 同时就绪为何不按顺序执行

如果一个 select 里有两个或更多通信 case 同时可以完成，Go 不会按代码从上到下固定执行第一个。规范给出的规则是：从所有可进行的通信中均匀伪随机选择一个。因此，想让高优先级消息稳定先处理，不能只把它写在第一个 case，而要把优先级表达成单独的选择结构。

官方地址：https://go.dev/ref/spec#Select_statements

select 同时就绪时到底按什么规则选

select 先确定各通信操作是否可进行。若只有一个 case ready，它自然会被选择；若有多个 case ready，运行时从这些可进行的通信中选择一个。这里的“均匀伪随机”不是“哪个消息先到就一定先执行”，也不是“源码排在前面的更优先”。

需要区分两个容易混淆的概念：进入 select 时，通信操作涉及的 channel 和发送值表达式按源码顺序求值；求值完成后，多个可执行通信的选择仍遵循伪随机规则。图1把这两个边界分开，便于排查“为什么第一个 case 没有命中”。

为什么把高优先级 case 写在前面仍然不可靠

下面的例子同时向两个缓冲 channel 写入数据。两个发送操作都能立即完成，但 select 不承诺优先选择第一个分支；输出顺序可能变化。示例只用于说明选择规则，不把某次输出当成固定结果。

package main

import "fmt"

func main() {
	fast := make(chan string, 1)
	normal := make(chan string, 1)
	fast 

如果测试只运行一次，恰好看到“高优先级”先输出，也不能据此断言顺序稳定。对业务来说，更重要的是先定义：消息是否必须优先、普通消息是否允许延迟、长期没有普通消息时是否要避免饥饿，再选择结构。

需要优先级时，用两层选择表达意图

一种常见做法是先用一次带 default 的短探测检查高优先级通道；如果此刻没有高优先级消息，再进入阻塞等待，同时监听两类通道。这个 default 只执行一次，不要把它包在没有休眠或取消条件的忙循环里。

func receive(fast, normal 

两层结构表达的是“优先消费已经可得的高优先级消息”，不是严格的实时优先级锁。进入第二层后，如果两个 channel 同时 ready，Go 仍可能选择普通消息。若必须严格优先，应改成循环中再次探测高优先级、处理取消信号，并为普通消息设置可接受的等待上限。

测试和设计时的检查清单

测试时不要把单次输出写成固定顺序断言。可以让两个 channel 都准备好多轮，验证结果集合和退出条件；如果要测优先级，则分别覆盖“高优先级已就绪”“只有普通消息”“两者同时就绪”和“收到取消”四种状态。

常见问题

case 写在第一行，为什么还可能先执行第二行？

因为多个通信都 ready 时，Go 从可执行 case 中均匀伪随机选择，源码排列不表示优先级。

select 会按消息到达时间选择最早的那个吗？

不会。到达时间可能影响某一时刻哪些 case ready，但同时 ready 的 case 之间仍按规范选择，不提供严格的先到先服务承诺。

两层 select 能保证高优先级永远先处理吗？

不能完全保证。它能优先消费探测时已经到达的高优先级消息；统一等待阶段若两者同时 ready，仍需用循环探测、配额或等待上限表达更强的业务约束。