go中可用container/heap实现优先队列，需自定义类型实现heap.interface接口，less决定优先级，pop自动重排，无peek方法；消费时应控制worker数量并处理panic与空队列。
用 container/heap 实现可排序的优先队列
Go 标准库没有开箱即用的优先队列，但 container/heap 提供了底层支持——它不直接是队列，而是一套堆操作接口，需要你包装一个切片并实现 heap.Interface（即 Len()、Less()、Swap()、Push()、Pop()）。关键点在于：Less(i, j) 决定优先级高低：返回 true 表示 i 应该排在 j 前面（即更高优先级），所以高优先级数字小（如 0 > 1 > 2）时，写 p[i].Priority ；若想数字越大优先级越高，则反过来。
常见错误是只实现了 Less 却忘了 Push 和 Pop 必须操作底层切片（*[]T），否则 heap.Push 不会真正插入元素。示例结构体通常长这样：
type Task struct {
ID string
Priority int
Payload interface{}
}
type PriorityQueue []*Task
func (pq PriorityQueue) Len() int { return len(pq) }
func (pq PriorityQueue) Less(i, j int) bool { return pq[i].Priority
<h3>并发安全必须自己加锁，<code>heap</code> 本身不保证</h3>
<p>标准 <code>container/heap</code> 是纯内存操作，零并发保护。如果你从多个 goroutine 调用 <code>Push</code>/<code>Pop</code>，大概率触发 panic 或数据错乱。最常用解法是封装一层带 <code>sync.Mutex</code> 的结构：</p>
- 锁粒度要覆盖整个操作：比如
Enqueue方法里先mu.Lock()，调完heap.Push再mu.Unlock() - 不要只锁 Push/Pop 而忽略遍历或 Peek（看顶元素）——只要读写共享切片，就得锁
- 避免在锁内做耗时操作（如网络请求、大计算），否则阻塞整个队列
另一个选择是用 sync/atomic + 无锁算法，但复杂度陡增，95% 场景用互斥锁更稳。
Pop() 返回的是最高优先级元素，不是随机一个
调用 heap.Pop(&pq) 永远弹出当前堆顶（即 Less 定义下的“最小”元素），不是 FIFO 或 LIFO。这意味着如果你按时间戳当优先级（越早越先执行），就设 Less 为 t1.Timestamp ；如果按业务权重（数值越大越紧急），就用 <code>t1.Weight > t2.Weight。别误以为 Pop 类似 slice 的 pop 操作——它会自动重排剩余元素，时间复杂度是 O(log n)。
想“偷看”但不取出？只能取 pq[0]（前提是已加锁且非空），container/heap 没提供 Peek() 方法。
任务执行模型：Pull 还是 Push？别混用 goroutine
队列本身只是容器，消费逻辑得另外写。典型模式是起一个或多个 worker goroutine，循环 Pop 并处理：
for {
task := q.Pop().(*Task) // 加锁后调用
go func(t *Task) {
defer wg.Done()
process(t)
}(task)
}
容易踩的坑：
- 没控制并发数：直接
go process(task)可能瞬间拉起上千 goroutine，压垮系统。应配合semaphore或固定 worker 数量的 channel 模式 - 忘记 recover：任务函数 panic 会导致 worker 退出，后续任务无人处理。应在 goroutine 内包一层
defer func(){recover()}() - Pop 空队列没判断：
heap.Pop在空堆上 panic，必须先if q.Len() > 0
真正难的不是堆怎么建，而是任务生命周期管理：超时取消、重试策略、失败归档——这些都得在 process 外围补全，container/heap 一概不管。
