Go select 同时有多个就绪分支时怎么选择

Go 的 select 不会按 case 从上到下挑选分支。只要多个发送或接收操作在同一时刻都能继续，语言规范规定它会从这些可执行通信中做均匀伪随机选择。因此，“把重要分支写在第一个 case”不能形成优先级，也不能拿某一次运行的输出顺序当作契约。

官方规范：https://go.dev/ref/spec#Select_statements

先确认哪些分支是真的就绪

接收一个有数据的 channel、向有空间的 buffered channel 发送，或者与另一端已经匹配的无缓冲发送/接收，都可能成为可执行通信。关闭的 channel 在接收方向上也会立即返回零值和 ok == false；向已关闭 channel 发送则不是一个可正常选择的发送路径。nil channel 永远不会完成通信。

下面的示例故意保留两个同类型分支。它表达的是“两个来源都能提供消息时任选一个”，而不是“先读 urgent，再读 normal”。代码中的注释说明了观察重点，示例输出不应被当作固定结果。

package main

import "fmt"

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

多个就绪分支为什么不能靠 case 顺序决定

规范把 select 的执行分成几个阶段：先计算通信相关表达式，再判断哪些通信可以继续；如果至少一个通信可执行，就从中选择一个。这个选择是均匀伪随机的，所以统计上各分支机会相近，但单次调用、短样本或某个具体调度时刻都不保证平均。

这也解释了两个常见误判。第一，分支写在前面不等于更重要；第二，连续多次看到同一分支，不代表另一个分支永远不会被选中。若业务要求“紧急消息绝不能被普通消息抢先处理”，就不能把两个来源直接放进同一个依赖顺序的 select。

需要优先级时，先做一次非阻塞探测

一种轻量策略是先用带 default 的小 select 探测高优先级通道；探测到数据就立即处理，否则再进入包含普通通道的阻塞等待。这样可以保证“在探测瞬间已经就绪的 urgent 优先”，但它不是抢占式调度：探测结束后才到达的 urgent，仍可能与 normal 同时就绪。

for urgent != nil || normal != nil {
	// 第一层只检查已经到达的高优先级消息，不等待。
	select {
	case msg, ok := 

如果优先级必须严格、可证明，通常应让一个协调 goroutine 接收所有输入，再由它按照业务规则放入下一阶段队列，或把决策写成显式状态机。非阻塞探测适合“尽量先处理”，不适合宣称绝对公平或绝对抢占。

default、关闭通道和 nil 通道的落地清单

最后检查一件事：如果循环同时等待输入和取消信号，把 放进阻塞式 select，并在命中后返回。这样即使某个业务 channel 一直没有消息，协程也能按约定回收。

相关问题

把优先级 channel 写在第一个 case 有用吗？

没有。它不会改变多个就绪分支的均匀伪随机选择；要表达优先级，应使用先探测、单独仲裁或显式状态机。

select 里加 default 会不会更快？

它只代表“当前没有通信可执行时立即继续”。如果外层循环没有退避，反而可能持续占用 CPU；等待事件时一般不要无条件使用 default。

把 select 看成“从当前可执行通信集合中做一次选择”，而不是带顺序的 switch，就能正确判断结果、设计优先策略，并处理好 channel 的生命周期。