Go select 为什么多个就绪分支不是固定优先级

如果你把两个已经有数据的 channel 写成两个 case，然后发现前面的分支并没有每次都先执行，这不是 Go 忽略了代码顺序，而是 select 的规定本来就不是“从上到下匹配”。当多个通信操作同时可以继续时，Go 会在这些可行分支中做均匀伪随机选择。

需要固定优先级时，不要依赖 case 的排列位置；先用一次非阻塞的优先检查，再进入普通 select。

先把“就绪”现场分成三类

排查时先问每个通信操作当前能不能完成。接收 case 的 channel 中已有值，或者 channel 已关闭，接收就绪；发送 case 的接收方已经等待，发送也可能就绪。只有一个 case 就绪时，结果看起来像固定优先级；多个 case 同时就绪时，顺序就不再提供保证。

package main

import "fmt"

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

这段代码的关键不是哪一行输出，而是两个缓冲 channel 都提供了可完成的接收。若某次观察得到 left，只能说明这次选择了左分支，不能推出下一次仍然选择左分支。

为什么前面的 case 不会获得优先级

Go 规范把 select 的执行拆成几步：先按源码顺序求出通信操作及其要发送的值；接着，如果有一个或多个通信可以继续，就从可继续的通信中选择一个；选中后才执行通信和对应语句块。第二步的规则明确是均匀伪随机选择，因此不存在“第一个可用 case 永远胜出”的语言保证。

这也解释了一个常见误判：把统计上暂时出现次数较多的分支当成优先级。伪随机选择不承诺每个短窗口严格一半，也不承诺跨版本、跨运行次序可复现。业务代码只能依赖“所有就绪分支都有机会被选中”这一语义。

怎样观察结果而不把观察当成保证

如果需要排查是否确实存在多个就绪分支，可以在循环里分别计数。计数用于发现某个分支是否长期没有机会，不用于证明某个 case 的优先级。

package main

import "fmt"

func main() {
	first := make(chan struct{}, 1)
	second := make(chan struct{}, 1)
	counts := map[string]int{"first": 0, "second": 0}

	for i := 0; i 

排查时应同时检查两件事：一是每个分支是否确实有独立的就绪来源，二是是否有其他 goroutine 在消费其中一个 channel。若就绪集合本身不稳定，结果波动不一定来自 select 的选择规则。

真正需要优先级时，改成显式的两层判断

例如关闭信号比普通任务更重要，可以先尝试一次不阻塞的优先接收；优先信号当前没有就绪时，再进入包含普通任务的 select。这样表达的是“优先信号已经就绪时先处理”，而不是承诺它一旦稍后到达就能打断已经开始的普通工作。

func consume(priority 

这是一种明确的优先处理模式，但它仍不是硬实时抢占：两层判断之间可能发生状态变化；如果两个 case 在第二层同时就绪，第二层的 select 仍按均匀伪随机规则选择。因此，若业务要求绝对顺序，还需要把事件统一送入一个拥有明确排序规则的队列或状态机。

三个容易把结果看错的边界

• nil channel：对 nil channel 的通信永远不能继续；没有其他可行分支且没有 default 时，select 会一直阻塞。
• 关闭 channel：关闭后的接收可以立即完成，并持续得到元素类型的零值；需要用双返回值判断 ok，否则它可能持续抢占其他分支。
• default：只要没有通信可继续就立即执行；它不是低优先级 case，也不会让其他 case 获得固定优先级。

相关问题

为什么只有一个 channel 时看起来总是按顺序执行？因为就绪集合只有一个元素，选择规则没有可竞争的分支。

能不能通过调整 case 顺序实现优先级？不能。顺序可以改善阅读性，但不能改变规范定义的选择语义。

怎样判断问题是调度还是业务逻辑？先记录每轮的就绪来源和分支计数；如果业务有硬优先级，再使用显式优先检查或集中式队列，而不是解读随机样本。