用 priorityqueue（最小堆）实现 top-k 更省空间，因其仅维护 k 个元素、空间复杂度 o(k)，而全量排序需 o(n) 空间；java 中需用默认最小堆并正确比较，python 中应避免直接堆化可变对象。
为什么用 PriorityQueue 实现最小堆找 Top-K 更省空间
直接遍历 + 排序整个集合（比如 list.sort() 或 sorted()）看似简单，但当数据量远大于 K（例如 1000 万条日志里找前 100 个最大响应时间），你就在为不需要的结果分配内存和排序开销。而 PriorityQueue（Java）或 heapq（Python）维护一个大小恒为 K 的最小堆，每来一个新元素只做 O(log K) 比较和可能的替换，总时间复杂度压到 O(N log K)，空间稳定在 O(K)。
常见错误现象：PriorityQueue 默认是**最小堆**，但有人误以为它能直接 pop 出最大值；或者把 K 个最大元素误存成最大堆——结果一 poll 就把最大的弹走了，留下的反而是小的。
- 始终用最小堆存 Top-K：堆顶是最小的那个，新元素比它大才入堆，保证堆里永远是“见过的最大 K 个”
- Java 中
PriorityQueue构造时别漏传Comparator.reverseOrder()——那是最大堆，不适合 Top-K 场景 - Python 的
heapq没有内置最大堆，要取负或用heapq.nlargest(K, iterable)，但后者会一次性加载全部数据，不适用于流式场景
Java 里怎么写一个健壮的 Top-K 提取逻辑
核心是控制堆大小、正确比较、处理 null/重复/边界值。别直接往 PriorityQueue 里塞原始对象——除非它实现了 Comparable 且语义符合你的“大”“小”定义。
使用场景：日志分析、实时排行榜、监控指标阈值告警。
- 用泛型 + 自定义
Comparator，明确指定按哪个字段比，比如Comparator.comparingLong(item -> item.responseTime) - 入堆前判空：如果元素字段可能为
null，Comparator里要用Comparator.nullsLast()，否则抛NullPointerException - 堆满后，用
queue.peek()拿堆顶（最小值），再和当前元素比较；只有当前更大才poll()+offer()，避免无谓操作 - 最后导出结果时记得反转顺序——最小堆里出来的是从小到大，而你要的是“Top-K”，通常需倒序输出
Python heapq 的三个易错点
heapq 不是类，是函数集合，没有“堆对象”的封装感，容易误用。最常踩的坑不是算法逻辑，而是 Python 特有的引用和可变性问题。
常见错误现象：用 heapq.heappush(heap, item) 塞了一个字典或列表，后续修改了这个变量，堆里对应项也变了；或者用 heapq.nsmallest() 却传了生成器，导致多次迭代出错。
- 不要对可变对象（如
dict,list）直接建堆——改原对象会影响堆结构；要么转成tuple（不可变），要么深拷贝后再入堆 -
heapq.heapify()是就地修改，原 list 被重排；如果不想破坏原始数据，先copy.copy()或切片data[:] - 流式数据（比如文件逐行读）别用
nlargest/nsmallest，它们内部会把整个 iterable 转成 list；老实用heapq.heappushpop()或手动维护固定大小的堆
性能敏感时，K 取多大开始不划算
当 K 接近 N 的 10% 以上（比如 N=100 万，K=20 万），堆操作的常数开销和缓存局部性劣势就开始暴露。此时快速选择（QuickSelect）平均 O(N) 更优，虽然最坏 O(N²)，但工程中加随机打乱或三数取中后极难触发。
兼容性影响：Java 里 PriorityQueue 是 JDK 1.5+ 标准类；Python heapq 从 2.3 就存在，但 heapq.merge() 等高级用法在 3.5+ 才稳定。旧环境慎用 heapq.heapreplace() 替代 heappushpop() 的写法。
- K
- 100 ≤ K ≤ N/10：依然推荐堆，代码简单、内存可控、实测稳定
- K > N/10：考虑
QuickSelect或部分排序（如 Java 的Arrays.parallelSort()配合截断） - 特别注意：如果数据已基本有序，堆的 log K 优势会被削弱，而部分排序可能更快
真正麻烦的从来不是选哪种结构，而是没想清楚“Top-K”到底指什么——是去重后的？按时间最新优先？相同值怎么排序？这些业务规则一旦嵌进堆比较逻辑里，调试成本就上去了。
