Go运行时无goroutine优先级，需用container/heap构建有序队列并手动分发；sync.Pool缓存任务节点会导致数据污染，应每次新建Task并Pop后清空字段；heap.Less须满足严格弱序，同优先级需用seq保证FIFO。
Go 运行时本身不感知优先级，goroutine 一律平等；所谓“高优任务先执行”，必须靠你自己用 container/heap 搭建可排序的队列 + 显式分发逻辑，别指望 select 或 channel 自动帮你排座次。
为什么不能用 sync.Pool 缓存任务节点
很多人想复用 Task 结构体减少 GC，往 sync.Pool 里塞节点再配 heap.Push——这会引发静默数据污染：池中对象被复用后，原堆内指针可能指向已覆盖内存，导致高优先级任务实际执行的是低优先级的 Fn。压测中常见“P0 任务跑出 P2 行为”的诡异现象。
-
sync.Pool不保证顺序，也不保证状态干净，和优先级队列的确定性要求天然冲突 -
heap.Push后若节点被回收，底层数组元素可能被后续Get()覆盖，而堆结构对此毫无感知 - 真正轻量的做法是：每次新建
Task，Pop后清空字段（如task.Fn = nil），让 GC 处理，代价远低于错乱调度
container/heap 实现时 Less 必须满足严格弱序
Less(i, j int) bool 返回 true 表示 i 应该排在 j 前面；但若两个任务优先级相等，你返回 false，堆可能随意交换它们位置，破坏 FIFO。这不是 bug，是设计使然。
- 高优数字小 → 用最小堆：
return q[i].Priority - 高优数字大 → 用最大堆：
return q[i].Priority > q[j].Priority（注意不是>=） - 同优先级必须稳定：加一个单调递增的
seq uint64字段，Less中第二层比q[i].seq - 别用
time.Now().UnixNano()当 seq——纳秒时间在高并发下会重复，且不如原子计数器可控
如何安全地动态修改正在队列中的任务优先级
heap 包不暴露索引映射，直接改 task.Priority 后不调整位置，下次 Pop 就可能漏掉它。标准解法是维护反向索引，但要注意并发。
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Map存*Task → index，避免全局锁拖慢Push -
Push后立即调Store(task, len(q)-1)记录位置 -
Swap方法里必须同步更新两个节点的index字段 - 改优先级前先
Load出索引，再调heap.Fix(&q, idx)——比全量heap.Init快，复杂度O(log n)
worker 取任务时别用 select+default 轮询
写成 select { case 看似能“优先消费”，实则不可靠：Go 的 <code>select 在多个 case 就绪时随机选，高优 channel 即便有数据，也可能被跳过；更糟的是，default 分支会让 worker 空转耗 CPU。
- 正确做法是阻塞式取堆顶：
task := heap.Pop(&q).(*Task)，配合sync.Mutex保护整个 Pop 流程 - 如果任务带执行时间（
DueAt），Pop 后用time.Until(time.Unix(task.DueAt, 0))判断是否到期；未到期就heap.Push回去（注意重新加锁） - 别在 worker 循环里调
runtime.Gosched()试图“让出”给低优任务——调度器不认这个，只会增加上下文切换开销
最易被忽略的点：所有对堆底层数组的读写（包括 Len、Less、Swap）都必须发生在锁内；但锁粒度不能太大——比如 Pop 中的函数执行（task.Fn()）必须在锁外，否则整个队列会被阻塞。
