go语言无协程优先级调度，goroutine在gmp中完全平等；所谓“加权channel选择”是应用层用select+多channel+控制逻辑模拟的软性优先级，高优channel必须前置且不可依赖随机性。
Go 语言没有协程优先级调度机制，goroutine 在运行时调度器（GMP）中完全平等——这不是缺陷，是设计取舍。所谓“加权 channel 选择”，本质是应用层用 select + 多 channel + 控制逻辑模拟的软性优先级，不是真正的权重调度。
select 中高优 channel 必须前置，且不能依赖随机性
很多人写成这样：
select {
case t := <p>这会导致高优任务被跳过：只要 <code>lowPrioCh</code> 有数据，它就可能被选中，因为 <code>select</code> 对所有就绪 <code>case</code> 是**伪随机**选取的，不按顺序。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill6460" title="Golang Naming"><img
src="https://img.php.cn/upload/skill/000/000/081/179094616043400.jpg" alt="Golang Naming" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill6460" title="Golang Naming" class="overflowclass">Golang Naming</a>
<p class="overflowclass">Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。</p>
</div>
<a rel="nofollow" href="/xiazai/skill6460" title="Golang Naming" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- 必须把高优
case放在最前面，且只放一次 - 避免重复写同一个
case（比如连写三次），这不会提高命中率，反而让代码难维护、易出错 - 如果高优 channel 缓冲已满，发送方阻塞，该
case就不算“就绪”，select会跳过它——所以缓冲大小要匹配实际吞吐，别设为 1 然后指望“立刻响应”
default 不是万能非阻塞开关，滥用会饿死高优任务
default 的作用是让 select 不阻塞，但它一旦执行，就意味着本轮什么都没处理。如果高频轮询 + default，而高优 channel 恰好短暂空闲，就会反复跳过，造成延迟累积。
- 加
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 缓冲溢出或内存压力间接拖慢高优。优先级永远只是业务逻辑层的分流策略，不是运行时特权。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
