go runtime不支持优先级调度，所有goroutine平等；需手动实现优先级队列+工作协程池，避免select随机性、channel伪优先级及context误用。
Go 里没有内置优先级调度器
Go 的 runtime 调度器（GMP 模型）不支持任务优先级：所有 goroutine 在调度层面是平等的，不会因为创建顺序、函数名或包路径而获得更高执行权。想靠 go func() {}() 加个参数控制优先级？不行——语法不支持，运行时也不认。
这意味着：如果你有一批并发任务（比如日志写入、API 响应、后台计算），不能指望 runtime 自动让“高优”任务先跑完。
常见错误现象：
• 用 select + 多个 case 模拟优先级，但 channel 无缓冲且发送方阻塞，导致“高优” case 实际被跳过
• 把高优任务塞进更短的 time.Sleep 后启动，结果因调度随机性反而更晚执行
• 误以为 runtime.Gosched() 能让出后立刻轮到某 goroutine，其实只是提示调度器“我可以换人了”，不指定换谁
手动实现优先级队列 + 工作协程池
真正可控的做法是：自己管理任务分发，把优先级逻辑从调度层移到业务层。核心是两部分：priorityQueue（最小堆或最大堆）存待执行任务，一组固定数量的 worker goroutine 从队列取任务执行。
立即学习“go语言免费学习笔记（深入）”；
使用场景：
• HTTP 请求中区分 admin 接口（高优）和用户查询（低优）
• 微服务内部消息处理，需要保障心跳/告警类消息比统计上报更快送达
type Task struct {
Priority int
Fn func()
}
// 用 container/heap 实现 *最小堆*，Priority 值越小越先出队
// 注意：不是“越大越优先”，避免负数和零值引发边界问题
实操建议：
• 不要直接用 map 或 slice 手写堆逻辑，容易在 Push/Pop 时索引错位
• 优先级字段建议用 int8 或 int32，别用 string（排序开销大，且无法做数值比较）
• 队列需加锁（sync.Mutex）或用 sync/atomic 控制计数，但别锁整个 Pop 过程——只锁结构体修改部分
channel 选路 + select 超时不是优先级，是竞态
很多人用多个带缓冲的 channel 分别接高/中/低优任务，再在 worker 里 select 多个 case。这看起来像优先级，其实是伪命题：Go 的 select 在多个可读 channel 同时就绪时，会**随机选择一个**，不按书写顺序，也不按 channel 容量。
常见错误现象：
• 高优 channel 缓冲满，低优 channel 空着，但 select 仍可能挑中低优 case（因为“可读”状态已满足）
• 加 default 做非阻塞尝试，结果高优任务被反复跳过，堆积在 channel 里触发 panic: send on closed channel
实操建议：
• 如果坚持用 channel，必须让高优通道始终“可读”——比如用 chan struct{} 做信号，配合 for range 检查是否还有高优任务待处理
• 更稳妥的是放弃 select 多路复用，改用循环轮询：if highQ.Len() > 0 { exec(highQ.Pop()) } else if midQ.Len() > 0 { ... }
• 别给不同优先级 channel 设不同缓冲大小来“暗示”优先级——runtime 不解析这种暗示
context.WithDeadline 和抢占式取消 ≠ 优先级调度
有人把给高优任务传 context.WithDeadline、低优任务传 context.WithTimeout 当成优先级控制。这是误解：context 只管“什么时候该停”，不管“什么时候该开始”。它解决的是超时/取消，不是抢占或调度顺序。
性能影响：
• 频繁调用 context.WithCancel 创建新 context 会分配内存，对 QPS 上万的服务有 GC 压力
• 如果高优任务因 context 被 cancel 而退出，但底层 goroutine 并未真正终止（比如正卡在系统调用），实际资源没释放
实操建议：
• 优先级调度和 context 取消要正交设计：先由队列决定谁先跑，再由 context 决定它能跑多久
• 避免在 Fn 函数里直接调用 ctx.Done() 做轮询——用 select 包一层更清晰
• 不要用 context.Background().WithCancel() 作为默认值传入，容易泄漏 cancel func
复杂点在于：优先级不是单维的。一个任务可能“高时效性但低 CPU 占用”，另一个“低时效性但必须独占 I/O”，这时候光靠数字 priority 不够，得结合资源类型做复合判断。这点常被忽略——代码写了 priority 字段，上线后发现磁盘 IO 阻塞了所有高优网络请求，才意识到没隔离资源维度。
