应使用 threading.Lock 包裹 heapq.heappush() 和 heappop() 实现线程安全优先级队列；优先级字段须可比较且越小越优先，推荐结构为 (priority, insertion_counter, task)，避免不可比较类型如字典。
用 heapq 实现线程安全的优先级队列，别直接封装 list
Python 标准库的 heapq 本身不提供线程安全保证，但它是实现高效优先级队列的唯一合理基础——手写堆逻辑或用 sorted() 都会破坏 O(log n) 入队/出队性能。关键不是“要不要用”，而是“怎么包裹”。直接对 list 调用 heapq.heappush() 和 heapq.heappop() 是正确起点，但必须加锁；不要试图自己维护堆序或用 queue.PriorityQueue 当底层（它内部已加锁，但阻塞语义和异常处理反而增加干扰）。
-
heapq操作原地修改列表，空间零开销，比每次sorted()或min()扫描快两个数量级以上 - 锁粒度要细：只在
heappush()/heappop()调用前后加threading.Lock，避免把业务逻辑也锁住 - 不要用
queue.PriorityQueue替代——它为生产者-消费者模型设计，get_nowait()抛queue.Empty，而你往往需要区分“空”和“无高优任务”，且无法原子性地 peek + pop
优先级字段必须可比较，且越小越优先——别反着定义
Python 的 heapq 是最小堆，heappop() 永远返回最小元素。如果业务上“1=最高优先级”，那直接用数字当优先级没问题；但如果误把字符串如 "high"、"low" 当优先级，或用时间戳但没取负，就会导致低优任务先执行。更隐蔽的坑是元组优先级中混入不可比较类型（比如 (priority, task_id, obj) 中 obj 是自定义类且没实现 __lt__）。
- 推荐结构：
(priority, insertion_counter, task)——insertion_counter是单调递增整数，确保相同priority时按插入顺序出队，且所有字段都可比较 - 绝对避免：
(priority, task_dict)，因为字典不可比较，运行时报TypeError: ' - 时间戳优先级要小心：用
time.time()作 priority 时，若希望“越早提交越先执行”，就直接用原值；若希望“越晚提交越先执行”，才用-time.time()
并发场景下，pop 前必须检查是否为空，且不能依赖 len() 判断
即使加了锁，len(queue) > 0 和后续 heappop() 之间仍存在竞态窗口：另一个线程可能在检查后、pop 前就把最后一个元素取走了。Python 的 heapq 对空堆调用 heappop() 会抛 IndexError，这是预期行为，不是 bug。
- 正确做法：在锁内先尝试
heappop()，捕获IndexError并返回None或其他哨兵值 - 错误模式：
if queue: return heappop(queue)—— 这里if queue触发__bool__，本质是检查len(queue) > 0，和上面一样有竞态 - 如果需要非阻塞 peek，只能额外维护一个变量或用
queue[0]（但需确保 queue 非空，且不改变堆结构）
高吞吐场景慎用 heapq.heapify() 初始化，批量插入优先用 heappush
初始化含 N 个元素的队列时，heapq.heapify() 是 O(N) 时间，看似比 N 次 heappush()（O(N log N)）快，但实际中几乎总是后者更稳。因为 heapify() 要求输入是完整列表且一次性传入，而并发任务通常动态到达；若硬凑一批再 heapify，就引入了延迟和内存暂存开销。
立即学习“Python免费学习笔记（深入）”；
- 单次插入：无条件用
heappush(queue, item) - 批量导入（如启动时加载历史任务）：先收集到 list，再
heapify()，但之后仍走heappush流程 - 别在循环里反复
heapify()——比如每插入一个就调用一次，这会让复杂度退化成 O(N² log N)
真正难的不是堆逻辑，而是优先级定义是否覆盖所有业务维度（比如紧急程度+截止时间+资源权重），以及锁的持有时间是否被意外延长——比如在锁内做了 HTTP 请求或数据库查询，这会让整个队列卡住。把耗时操作移出临界区，是比选什么数据结构更关键的决定。
