heapq不提供现成优先级队列类，需用list配合heappush()/heappop()手动维护；误用heapify()后直接修改列表会破坏堆结构；线程安全需额外加锁或改用queue.PriorityQueue；元组元素须满足priority可比较且同优先级时item也可比较。
heapq 本身不直接提供优先级队列类，得自己封装
Python 的 heapq 模块只提供堆操作函数（如 heappush()、heappop()），没有现成的 PriorityQueue 类——这和 Java 的 PriorityQueue 或 C++ 的 std::priority_queue 不同。直接用 list 配合 heapq 函数是唯一轻量、高效的方式。
常见错误是误以为 heapq.heapify() 能“转换”一个普通列表为可自动维护的队列对象；其实它只是原地建堆，后续插入/弹出仍需手动调用 heappush()/heappop()，否则顺序立刻错乱。
- 不要对列表做一次
heapify()就当成队列用，必须所有增删都走heappush()/heappop() - 避免混用
.append()或切片赋值修改底层列表，会破坏堆结构 - 若需线程安全，不能只靠
heapq，得额外加threading.Lock或改用queue.PriorityQueue（但后者有锁开销）
元组作为元素时，优先级字段必须放最左且可比较
实际使用中，多数人用 (priority, item) 元组入堆，依赖 Python 元组的字典序比较规则。但这里有个关键约束：priority 必须是可比较类型（如 int、float），且 item 在 priority 相同时也要能比较——否则抛 TypeError: '。
典型踩坑场景：存入未定义 __lt__ 的自定义对象，或 item 是字典/列表等不可比较类型。
立即学习“Python免费学习笔记（深入）”；
- 稳妥做法：用计数器打破平局，例如
(priority, counter, item)，其中counter是递增整数 - 不要用
(priority, obj)且obj是dict或无序结构 - 如果
item本身含时间戳，别直接塞进元组第二位——时间戳相同时仍可能触发比较失败
heapq 的性能优势只在「大量动态插入+弹出」时才明显
heapq 的堆操作是 O(log n)，比每次 min() 扫描 O(n) 快得多，但这优势有前提：操作次数足够多，且数据不总是一次性就绪。
如果只是「有一堆数据，取最小的 k 个」，直接用 heapq.nsmallest(k, iterable) 比手动建堆再 pop k 次更优；如果是「数据流式到达，持续取当前最小」，才真正需要维护一个动态堆。
- 静态数据选
nsmallest()/nlargest()，它们内部做了优化，比手写循环快 - 避免对小规模数据（比如长度 heapq，函数调用和堆维护开销反而更高
-
heapq不支持按值删除或更新优先级——要实现这些，得用第三方库如heapq_plus或手写带索引的堆
注意 heapq 的最小堆特性与反向优先级的处理
heapq 只实现最小堆，即 heappop() 总返回最小元素。想实现最大堆（如取最大优先级任务），不能直接取负——对浮点数、None 或自定义对象会出问题。
正确做法是统一包装：要么在插入前对 priority 取负（仅限全为数字且无 -inf 等边界值），要么封装一层逻辑把「高优先级=小数值」映射为业务语义。
- 推荐方式：业务层约定
priority=0表示最高优先级，priority=100表示最低，这样天然适配最小堆 - 避免在堆里存
-priority后又忘记还原，导致后续逻辑用错符号 - 如果必须用最大堆语义且数据类型复杂，考虑用
queue.PriorityQueue并重载__lt__，但注意它内部用了锁，吞吐量更低
真正难的不是调用 heappush()，而是确保所有入队数据结构一致、比较行为可控、且生命周期内不被意外绕过堆接口修改。一旦堆结构被破坏，heappop() 返回的就不是真正最小值——这种 bug 很难复现，尤其在并发或混合数据类型场景下。
