Go select 同时命中多个 case 时如何避免误判优先级

当一个 select 里的多个 channel 同时可收发时，Go 不会按 case 的书写顺序固定执行。规范规定：多个通信都能继续时，会从可运行的通信中做均匀伪随机选择；只有一个通信能继续时才会选它；没有通信可运行时，才会落到 default 或阻塞。因此，把紧急 case 写在普通 case 前面，并不能形成优先级。

先确认 select 的可运行集合，而不是看 case 排列

把每个 case 看成一个候选通信：接收 case 需要 channel 中已有值，发送 case 需要接收方或缓冲空间，带计时器的接收还要等计时器到期。进入 select 时，Go 先评估通信操作的相关表达式，再从当前可运行集合中选一个。集合里只有一个成员时没有歧义；集合里有两个或更多成员时，源码上下位置不能作为业务证据。

需要优先级时，用两阶段探测表达意图

如果业务要求“已经存在的紧急信号先处理”，可以把紧急 channel 从普通选择集合里暂时拆出来：先用带 default 的小型 select 探测它，探测不到再进入普通任务选择。关键是，第二个 select 仍然遵守自己的随机选择规则，不能把它写成一个看似有序的大 select。

func poll(urgent 

这段写法的保护边界要说清楚：如果普通任务检查结束后，紧急信号才到达，那么本轮仍可能先处理普通任务。若业务要求更强的顺序，应让一个 goroutine 成为事件仲裁者，把输入归并到带明确优先级的数据结构中，而不是继续增加 case。

default 不是优先级开关，轮询还需要退避

带 default 的 select 会立即返回。把它放进无边界的 for 中，空闲时就会反复执行判断，形成忙等。可以按空闲次数逐步拉长短暂等待，并在收到任务后归零；退避上限应该由可接受的响应延迟决定，而不是凭感觉写一个很大的时间。

func worker(urgent 

如果任务本身允许阻塞等待，优先考虑去掉 default，让 select 等待 channel；只有确实需要周期性检查、可取消轮询或混合外部状态时，才使用非阻塞路径。退避解决的是空闲成本，不会改变多个 ready case 的选择规则。

用审计记录验证“优先级”是否真的生效

不要只看最终处理顺序。为每次选择记录来源、是否命中紧急探测、空闲次数、退避时长和从入队到处理的延迟，才能判断问题属于随机选择、普通任务处理过慢，还是紧急信号根本没有及时送达。记录应使用计数器和分位数，避免在高频循环里打印每一次空转日志。

• 保护资产：紧急信号的最大等待时间、普通任务的吞吐量和 worker 的 CPU 使用率。
• 攻击路径：误把源码顺序当优先级、把 default 当空闲证明、在空转时持续放大调度压力。
• 防护控制：两阶段探测、显式仲裁、退避上限和来源计数器。
• 验证清单：同时灌入两类任务，检查紧急延迟分位数；空队列运行一段时间，检查 CPU 是否回落；确认普通任务不会因强优先级长期饥饿。

常见问题

把紧急 case 写在第一个能提高命中率吗？

不能。只要多个通信同时可运行，Go 会在可运行集合中选择一个，case 的源码顺序不是优先级配置。

两个 select 连着写就能保证绝对优先吗？

不能保证绝对优先。它只能优先处理第一阶段探测时已经可见的紧急信号；第二阶段开始后新到达的信号仍可能与普通任务存在竞态。

为什么 default 会让 CPU 升高？

因为它让 select 立即返回，外层循环如果没有等待或退避，就会持续重复检查。给空闲分支增加短暂退避，或直接使用阻塞式 select，通常更合适。

判断 Go select 优先级时，先看可运行集合，再看业务是否需要显式仲裁。源码顺序只能帮助阅读，不能替代策略；而 default 只表示本次没有可立即通信的 case，也不能替代负载、延迟和公平性的观测。