绝大多数topn场景下，直接用heapq.nlargest或nsmallest更优，因其根据n大小自动选择排序（小n）或堆（大n）策略，而手动维护固定堆易出错且边界难处理。
heapq.nlargest 和 heapq.nsmallest 比手写 heappush/heappop 更快？
绝大多数 TopN 场景下，直接用 heapq.nlargest 或 heapq.nsmallest 更优，不是因为“封装好”，而是算法策略不同：它们内部对小 N 会走排序分支（O(k log k)），对大 N 才建堆（O(n log k)），而手动维护固定大小堆容易写错边界和初始化逻辑。
常见错误现象：heapq.heappushpop 在空堆上调用会抛 IndexError: index out of range；或误用 heapq.heapify 后反复 heappop 全部元素再取前 N，实际做了冗余工作。
- 当
n很小（比如n ）且数据量大时，<code>nlargest内部可能转为sorted(iterable, key=key, reverse=True)[:n]，比手动堆快得多 - 如果数据本身是生成器或不可重复迭代（如文件逐行读取），必须用手动堆——
nlargest会隐式转成 list，可能爆内存 - 注意
key参数：它只影响比较逻辑，不改变返回值本身；若需返回带权重的元组，别漏掉原始数据字段
手动维护大小为 N 的最小堆求 TopN 最大值时，为什么老是漏掉最大元素？
核心问题出在“堆顶是否该被替换”的判断逻辑上。很多人写成 if item > heap[0]: heapq.heapreplace(heap, item)，但前提是堆已满；如果初始堆没填满 N 个元素，就该用 heappush，而不是无条件 heapreplace。
使用场景：流式数据、内存受限、或需要在线更新 TopN（比如实时日志统计）。
立即学习“Python免费学习笔记（深入）”；
微信小程序是一种轻量级的应用开发平台，由腾讯公司推出，主要应用于移动端，旨在提供便捷的用户体验，无需下载安装即可在微信内使用。本压缩包包含了丰富的源码资源，涵盖了多个领域的应用场景，下面将逐一介绍其中涉及的知识点。1. 图片展示：这部分源码可能涉及了微信小程序中的``组件的使用，用于显示图片，以及`wx.getSystemInfo`接口获取屏幕尺寸，实现图片的适配和响应式布局。可能还包括了图片懒加
- 初始化必须先塞满 N 个元素：
heap = list(itertools.islice(iterable, n)); heapq.heapify(heap) - 后续每来一个新元素：
if item > heap[0]: heapq.heapreplace(heap, item)—— 注意是>，不是>=，否则相等元素可能被错误轮换 - 最终结果要
sorted(heap, reverse=True)，因为最小堆里元素无序，不能直接切片或反向遍历
heapq 不支持自定义比较？那怎么按对象属性取 TopN？
heapq 本身不提供 key 参数，但 Python 的 tuple 比较天然支持多级排序，这是最轻量、最安全的解法。别去重载 __lt__ 或用 functools.total_ordering，容易污染对象语义且线程不安全。
性能影响：tuple 封装增加少量内存开销，但远小于自定义类或 lambda 引入的函数调用开销；兼容性上，所有 Python 版本都一致。
- 正确做法：
heapq.nlargest(n, items, key=lambda x: x.score)—— 这里key是nlargest自带的，不是 heapq 堆操作本身的 - 手动堆场景下，存的是
(item.score, item)或(-item.score, item)（用负号转最小堆为最大堆） - 避免用
(item.score, id(item), item)防冲突——除非真有 score 完全相同还要稳定排序，否则id引入不必要的复杂度
TopN 结果要稳定排序（相同分数按原始顺序），heapq 怎么保序？
heapq 本身不保证稳定性，但 Python 的 tuple 比较是短路的，只要把“原始索引”作为第二关键字，就能自然实现稳定。
容易踩的坑：有人用 enumerate 后直接 nlargest(n, enumerated_items, key=lambda x: x[1].score)，结果丢掉了索引信息；或者把索引放前面导致主排序失效。
- 正确组合：
(-score, index, item)—— 负分确保最大堆行为，index保证相等时按输入顺序排 - 如果数据来自文件或数据库，用
itertools.count()生成索引比range(len(...))更省内存 - 注意：
nlargest的key参数无法保留原始位置信息，所以稳定排序必须走手动堆 + 索引元组路线
真正麻烦的从来不是选哪个函数，而是想清楚：数据是一次性加载还是流式？N 相对于总长度有多大？要不要保序？有没有重复分数？这些决定了你到底该进哪条分支——而不是背 API。
