Go select 同时就绪时为什么不能依赖分支顺序

我排查并发代码时，最容易被误读的一行通常不是复杂算法，而是两个都能接收的 select。如果把写在上面的 case 当成“优先处理”，代码在某些时刻看起来没问题，压力一上来却会出现顺序变化。结论很明确：多个通信同时就绪时，Go 会从可执行的通信中做均匀伪随机选择，case 的书写顺序不是优先级。

为什么源码排在前面的 case 不能当成优先级

select 的规则可以拆成两层。第一层是进入语句时，接收通道、发送通道以及发送值会按源码顺序求值；第二层才是选择通信。如果一个或多个通信已经可以继续，规范要求从这些候选中选择一个，而不是扫描到第一个就停下。因此下面两个分支没有“urgent 优先”的含义：

select {
case msg := 

这条规则的好处是避免某个长期就绪的通道把其他通道永久饿住，但代价是不能依赖输出顺序。尤其不要用“连续观察几次都是 urgent”来反推语言保证，那只是一次运行中的样本。

把调用方真正需要的顺序写成选择策略

先问清楚需求是“不等待”、 “尽量先处理紧急消息”，还是“任何时候都不能让普通消息抢先”。这三种需求不能用同一段双 case 代码表达。

一个常见的尽力优先写法如下。第一层只负责“现在已经有 urgent 就先取”，第二层负责在没有取到时继续等待。它不能对并发到达的瞬间做绝对承诺，所以注释和接口文档要把这个契约说清楚：

func receive(urgent, normal 

如何检查 select 代码没有偷偷依赖顺序

评审时可以逐项检查：第一，多个 case 同时就绪时，业务是否允许任意一个先处理；第二，是否把 default 误写成“低优先级分支”；第三，通道关闭后接收是否会持续得到零值；第四，nil channel 是否会永久阻塞该通信。若关闭通道只是结束信号，应使用双值接收并及时移除或置 nil：

msg, ok := 

测试不要断言“第一轮一定走上面的 case”。更可靠的做法是验证每个分支都能被处理、关闭信号能结束循环，并把必须满足的优先级交给显式队列或仲裁器。这样测试的是接口契约，而不是某一次调度结果。

相关问题

select 的 case 顺序会影响通道表达式的求值吗？

会影响求值发生的源码顺序，但不会把可执行通信变成按顺序排队的优先级。发送值的副作用也可能在选择结果之前发生，因此表达式应保持简单。

有 default 就能实现优先级吗？

不能。default 只在没有任何通信可继续时被选择，不能把另一个 case 标成低优先级。

怎么实现严格的 urgent 优先？

让一个 goroutine 统一接收输入并按优先级放入队列，或在单一仲裁器内维护策略。双层 select 只能表达尽力优先。

nil channel 为什么常被用来改变 select 行为？

对 nil channel 的通信永远无法进行，把通道变量置 nil 可以动态禁用一个 case；但如果所有 case 都因此不可用且没有 default，select 会一直等待。

记住一句话就够了：select 选择的是“现在能通信的候选集合”，不是源码里最先写到的那一行。顺序需求必须成为代码中的策略和测试中的契约。