Go select 同时命中多个 ready case 时如何理解结果

Go 的 select 不是按 case 从上到下匹配的 switch。当多个发送或接收操作在同一时刻都能继续时，运行时会从这些 ready case 中选一个执行，而且选择是均匀伪随机的。因此，代码把高优先级通道写在第一行，并不能得到优先级保证。

多个 case 同时 ready 时，select 只承诺选一个，不承诺选排在前面的那个。若业务需要优先级，必须把优先级判断写成额外的控制逻辑。

多个 ready case 为什么不会按书写顺序优先执行

把 channel 做成容量为 1 的缓冲通道，并提前各放入一条消息，两个接收 case 就同时具备执行条件。下面的程序每次只会打印一个通道的消息；反复运行时，结果可能不同。

package main

import "fmt"

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

这里的关键不是“随机数导致代码不稳定”，而是 select 的语义本来就允许从可继续的通信中做均匀伪随机选择。Go 规范把它与“没有 ready case 时是否阻塞”分开定义：有可执行通信时选一个，没有时才看 default 或进入等待。

判断 ready 时还要分清通信和表达式求值

进入 select 时，各 case 的 channel 操作数，以及发送操作右侧的值，会按源代码顺序求值一次。这个规则不等于“第一个 case 先执行”。例如，函数调用产生的副作用可能已经发生，但对应 case 最终并没有被选中。

实际排查时可以把问题拆成两层：先问哪些通信能够继续，再问被选中的 case 体会做什么。接收语句左侧的赋值发生在选中通信之后；关闭的 channel 仍然可以接收，但需要用双值接收判断 ok，否则可能把关闭信号误读成有效零值。

需要优先级时如何改写 select

如果业务要求“高优先级消息已经在队列中时先处理它”，可以先对高优先级通道做一次带 default 的非阻塞检查，再进入正常 select。第二次 select 仍可能遇到竞争：低优先级分支已经 ready，而高优先级消息在两次检查之间才到达时，运行时不能回溯第一次判断。

func receive(high, low 

这段写法适合“尽量优先”，不适合严格调度。如果高低优先级都必须有确定顺序，应使用单独的调度 goroutine、优先级队列或把消息合并后在一个消费者内排序。不要把顺序承诺寄托在 case 的排列上。

把随机选择写进并发代码检查清单

先确认设计是否真的需要公平地消费多个来源。日志、取消信号和多个同等重要的工作队列通常可以接受伪随机选择；严格优先级、配额和截止时间则需要显式调度。其次检查 channel 是否可能为 nil：nil channel 永远不能通信，会让没有 default 的 select 一直等待。最后检查关闭语义，接收循环要区分“收到零值”和“通道已关闭”。

带 default 的 select 是非阻塞尝试，不是“等待一小会儿”。如果调用方需要等待，应删除 default 或配合明确的 timer；如果只是轮询，必须评估空转带来的 CPU 消耗。

相关问题

select 的 case 顺序能不能当作优先级？

不能。只有一个 case ready 时结果才看起来固定；多个 ready case 同时存在时，选择不按书写顺序保证。

多个 case ready 时会不会全部执行？

不会。一次 select 只执行一个被选中的通信和对应语句体，下一轮循环才会重新判断。

关闭的 channel 为什么总是容易被选中？

关闭 channel 的接收可以立即完成，所以它会持续处于 ready 状态。读到关闭信号后应禁用该 channel 或退出循环，避免反复消费零值。