Go select 多分支 增加优先级仲裁

Go 的 select 不会因为某个 case 写在前面，就自动把它当成高优先级分支。只要多个通信操作同时可执行，语言规范允许从这些操作中做统一的伪随机选择。要让告警、取消或紧急控制消息先获得处理机会，常用做法是增加一层非阻塞探测，再进入包含普通分支的等待。

官方资料：https://go.dev/ref/spec#Select_statements

把“优先级”写成选择结构，而不是写成 case 的排列顺序：先探测高优先级 channel，未命中时再等待普通 channel；如果业务要求绝对顺序，则应把消息交给单一仲裁者排队。

为什么 case 排在前面也没有优先级

select 负责的是“哪一个通信现在可以继续”，不是“哪一个 case 更重要”。当高优先级 channel 和普通 channel 都已经有数据时，下面的写法不会稳定地先处理 high：

select {
case item := 

因此，简单地交换两个 case 的顺序，或者在高优先级分支旁边写更多注释，都不能改变选择语义。下面的结构图只展示通信来源、统一选择集合和消费者之间的静态关系，不是运行截图。

用两层 select 给高优先级消息一次先行机会

如果需求是“高优先级消息已经到达时尽快先处理”，可以把选择拆成两层。第一层带 default，只做一次立即探测；没有探测到 high 时，第二层才阻塞等待 high、normal 或取消信号。

package priority

import "context"

type Event struct {
	Kind    string
	Payload string
}

func Pick(ctx context.Context, high, normal 

这段写法的重点不是让 high 获得语言层面的绝对特权，而是把仲裁时机显式放在代码里：已经就绪的 high 会先被读取；high 暂时没有数据时，normal 不会被无限期饿死；普通分支被选中后再做一次短探测，可以覆盖一部分竞争窗口。

关闭与取消是优先级仲裁的一部分

channel 关闭后，接收操作会持续返回零值和 ok=false。如果代码忽略这个布尔值，关闭分支可能让循环反复被唤醒，表现为 CPU 占用升高。因此示例在发现关闭后把本地 channel 变量设为 nil；nil channel 永远不会准备好，能从后续选择集合中退出。

context.Done() 也不应被塞进“普通消息”逻辑里。它代表消费边界的退出信号，应该与 high、normal 并列处理，并在返回前释放调用方持有的资源。若 channel 的关闭由生产者负责，消费者只需要接收并清理自己的状态，不要在多个 goroutine 中重复关闭同一 channel。

软优先级和严格优先级怎么选

一个实用判断是：只要“高优先级已经在等待”就足够，使用两层 select；如果要求“任何时刻都不能先交付普通消息”，就不要把规则寄托在多个 goroutine 同时执行的 select 上，而应让一个拥有队列的仲裁者成为唯一出队点。

常见问题

把 default 放进同一个 select 能不能实现优先级？

不能。default 只表示没有通信立即可执行时走默认分支；它不会改变其他 case 之间的选择规则。需要优先探测时，应把高优先级探测单独放在外层 select。

高优先级 channel 一直有数据会怎样？

两层写法会倾向于持续处理 high，normal 可能延迟。若普通消息不能饿死，应在仲裁者中增加配额、时间片或批量上限；这已经属于调度策略，不是 select 语法本身提供的保证。

小结：Go select 的 case 顺序不是优先级配置。先探测、再等待可以实现清晰的软优先级；正确处理 ok=false、nil channel 和 context.Done()，才能让仲裁循环稳定退出；严格优先级则应集中到一个明确的队列所有者上。