Go语言无协程优先级调度，goroutine在GMP中完全平等；所谓“加权channel选择”是应用层用select+多channel+控制逻辑模拟的软性优先级，高优channel必须前置且不可依赖随机性。
Go 语言没有协程优先级调度机制，goroutine 在运行时调度器（GMP）中完全平等——这不是缺陷，是设计取舍。所谓“加权 channel 选择”，本质是应用层用 select + 多 channel + 控制逻辑模拟的软性优先级，不是真正的权重调度。
select 中高优 channel 必须前置，且不能依赖随机性
很多人写成这样：
select {
case t := <-lowPrioCh:
handle(t)
case t := <-highPrioCh:
handle(t)
}这会导致高优任务被跳过：只要 lowPrioCh 有数据，它就可能被选中，因为 select 对所有就绪 case 是**伪随机**选取的，不按顺序。
- 必须把高优
case放在最前面，且只放一次 - 避免重复写同一个
case（比如连写三次），这不会提高命中率，反而让代码难维护、易出错 - 如果高优 channel 缓冲已满，发送方阻塞，该
case就不算“就绪”，select会跳过它——所以缓冲大小要匹配实际吞吐，别设为 1 然后指望“立刻响应”
default 不是万能非阻塞开关，滥用会饿死高优任务
default 的作用是让 select 不阻塞，但它一旦执行，就意味着本轮什么都没处理。如果高频轮询 + default，而高优 channel 恰好短暂空闲，就会反复跳过，造成延迟累积。
立即学习“go语言免费学习笔记（深入）”；
- 加
default前先问：是不是真需要“立刻返回”？还是可以等几微秒？ - 更稳妥的做法是用
time.After或time.Tick控制最大等待时间，例如：case ，避免空转耗 CPU - 不要在高优路径里加
default；低优路径可加，但建议配合计数器或退避，防止低优长期霸占调度循环
加权 ≠ 权重数值，而是“尝试频次 + 时间窗口”的组合控制
所谓“加权”，不是给 channel 配个 weight: 3 字段，而是通过调度逻辑体现权重感。例如：
- 每轮调度中，高优 channel 尝试 3 次（用带
default的select循环），中优 1 次，低优仅当高/中都空闲时才查 - 用
time.Tick(100 * time.Microsecond)作为节拍器，每 tick 内优先处理高优，剩余时间再分给其他等级 - 权重最终反映在 **单位时间内高优任务的平均响应延迟** 和 **低优任务的最小保障执行频率** 上，而不是某个配置项的数字
真正容易被忽略的点是：没有“权重”能绕过 Go 调度器的公平性约束。如果高优任务本身是 CPU 密集型，它照样会被抢占；如果低优任务量极大，仍可能因 channel 缓冲溢出或内存压力间接拖慢高优。优先级永远只是业务逻辑层的分流策略，不是运行时特权。
