go语言协程无优先级调度机制，所有goroutine在gmp模型中一视同仁；高优逻辑需通过select顺序、缓冲区控制、节拍器等应用层手段实现，而非运行时支持。
Go语言没有协程优先级调度机制，这是明确的设计事实，不是待解决的“现状”，而是已落地的工程取舍。
Go运行时调度器（GMP）不支持goroutine优先级
所有goroutine在P本地队列、全局队列、netpoll中一视同仁——没有SetPriority()、没有runtime.Gosched()之外的抢占干预接口、也没有底层权重字段。所谓“高优协程更快执行”，只能源于你控制它的就绪时机、避免它被延迟唤醒，而非调度器给它更多CPU时间片。
select中高优channel必须前置，且不能靠重复case提升命中率
常见错误是把低优channel写在前面：select对所有就绪case伪随机选取，不按书写顺序；一旦lowPrioCh有数据，highPrioCh哪怕也就绪，也可能被跳过。
正确做法只有一条：高优case必须放在select最顶部，且仅出现一次。
缓冲区大小直接影响就绪判断——如果highPrioCh是无缓冲或缓冲已满，发送方阻塞，该case就不算就绪，select自然跳过它。
default不是非阻塞万能解，滥用会饿死高优任务
高频轮询+default看似“不卡住”，实则危险：
– 高优channel短暂空闲时，select反复走default分支，导致响应延迟累积
– 真正需要的是可控等待，比如用time.After(10 * time.Microsecond)替代default，既防卡死，又保响应
– default只应在低优路径谨慎使用，且建议配合计数器或退避逻辑，防止低优任务长期霸占调度循环
加权调度本质是应用层逻辑，不是配置项
不存在weight: 3这类字段，所谓“加权”只能靠代码结构体现：
– 每轮调度中，对高优channel尝试3次（带default的select循环），中优1次，低优仅当高/中均空闲时才查
– 用time.Tick(100 * time.Microsecond)做节拍器，在每个tick内优先处理高优，剩余时间再分给其他等级
– 权重最终反映在单位时间内高优任务的平均响应延迟，以及低优任务的最小保障执行频率上
真正容易被忽略的点是：无论你怎么设计“优先级逻辑”，只要高优goroutine本身是CPU密集型，它照样会被调度器抢占；只要低优任务量极大，仍可能因channel缓冲溢出或内存压力间接拖慢高优。优先级永远只是业务层的分流策略，不是运行时特权。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
