Go语言必须用container/heap封装实现优先级队列，因slice+sort全量排序为O(n log n)、不维护堆序，调用heap.Pop会返回错误元素甚至panic；正解是定义满足heap.Interface的命名类型，五个方法缺一不可，且Push/Pop必须用指针接收器。
Go 语言里没有现成的优先级队列类型，必须用 container/heap 自己封装；直接用 []*Task + sort.Slice 每次取最大值，性能差、线程不安全，不是正解。
为什么不能直接用 slice + sort 实现优先级队列
每次插入或取任务都全量排序是 O(n log n)，而堆的 Push/Pop 是 O(log n)。更关键的是：sort 不维护堆序，heap.Pop() 依赖底层结构满足堆性质，乱序切片上调用会返回错误元素甚至 panic。
-
heap.Pop(&pq)返回的不是最高优任务，而是某个随机位置的旧任务 - 漏调
heap.Init(&pq)（首次初始化）或误用值接收器实现Push/Pop，会导致切片修改不生效 - 并发场景下没加锁就直接操作切片，出现数据竞争或
panic: "concurrent map iteration and map write"
如何正确定义 Task 和 PriorityQueue 类型
核心是让自定义类型满足 heap.Interface，五个方法一个都不能少，且 Push/Pop 必须用指针接收器。决定优先级方向：返回 true 表示 i 应该比 j 更早被 Pop 出来；数值越小越紧急就写 pq[i].Priority 。
- 任务结构体建议带
Timestamp time.Time字段，避免同优先级时顺序不确定 - 不要用匿名结构体或字面量初始化队列，例如
pq := PriorityQueue{}可能不可寻址；应写var pq PriorityQueue或pq := new(PriorityQueue) -
Less方法中需处理相等优先级的稳定排序（如按时间戳），否则 Go 堆不保证 FIFO
并发安全的任务队列封装要点
单纯给 Push/Pop 加锁不够——heap.Init、heap.Fix 等操作也需同步；推荐封装成结构体，把锁、堆实例和条件变量（如需要阻塞取任务）一起管理。
- 不要在锁内做耗时操作（如处理
Payload），只做入队/出队 -
sync.RWMutex对读多写少场景无意义，因为heap.Push/Pop都要写底层数组，一律用sync.Mutex - 所有
heap操作都传&pq，包括heap.Init(&pq)、heap.Push(&pq, x)、x := heap.Pop(&pq) - 如果队列嵌在 struct 里（如
type Worker struct { queue *PriorityQueue }），确保该字段是指针类型，否则每次复制 struct 都丢掉堆状态
运行时修改某任务优先级的正确姿势
container/heap 不提供 Update 方法，必须手动定位索引并调 heap.Fix。这是最容易被忽略的复杂点。
- 任务结构体需额外加
index int字段，Push时设为当前长度 -1，Swap时同步更新两个元素的index - 修改优先级后，先改字段值，再调
heap.Fix(pq, task.index)，否则堆结构错位 - 如果任务来源不可控（比如从
channel收到），无法预埋index，那就只能Pop全部重排，或换用第三方库如github.com/emirpasic/gods/trees/binaryheap - 别在
Push方法里再调heap.Push——会递归死循环
真正难的不是写完五个接口方法，而是理解 index 字段怎么随 Swap 同步、Fix 在哪一刻必须介入、以及为什么所有 heap 操作都得传指针——这些细节一旦漏掉，队列会在高并发或优先级动态调整时悄无声息地返回错乱结果。
