heapq.nlargest/nsmallest是取前N个极值的首选方法，内部自动选择堆或排序策略；n=1时用max/min更优，大数据量且n接近全长时sorted切片更佳。
用 heapq.nlargest 和 heapq.nsmallest 直接取前N个极值
绝大多数情况下，不需要手动建堆或排序——heapq.nlargest 和 heapq.nsmallest 就是为此设计的。它们在内部自动选择最优策略：当 n 远小于列表长度时，用堆；当 n 接近全长时，退化为 sorted() 加切片，实际性能反而更好。
常见错误是先调用 heapq.heapify 再反复 heappop，这不仅代码啰嗦，还可能因破坏原列表顺序引发副作用。
-
heapq.nlargest(3, [1, 8, 2, 9, 4])返回[9, 8, 4]（已按降序排列） -
heapq.nsmallest(2, ['apple', 'banana', 'cherry'], key=len)返回['apple', 'cherry']（按字符串长度取最小） - 若需稳定顺序（如保留原始索引位置），得额外记录索引，例如：
heapq.nsmallest(3, enumerate(data), key=lambda x: x[1])
什么时候不该用 nlargest/nsmallest？
当 n == 1 时，直接用 max() 或 min() 更快、更直观；当 n 接近列表总长（比如取前 90%），sorted(lst)[:n] 或 sorted(lst, reverse=True)[:n] 可读性更高，且 C 实现的 sorted 在大数据量下未必比堆慢。
另一个容易被忽略的点：这两个函数返回的是新列表，不修改原数据——但如果你误以为它们返回迭代器（像 heapq.merge 那样），就可能在链式调用中出错。
立即学习“Python免费学习笔记（深入）”；
- 错误写法：
for x in heapq.nlargest(5, data).reverse(): ...（reverse()返回None） - 正确写法：
for x in heapq.nlargest(5, data)[::-1]: ...或直接用heapq.nsmallest - 如果后续还要频繁查最大/最小值，才值得显式建堆：
heapq.heapify(data)，然后用heapq.heappop
自定义 key 的坑：不能传 lambda 给 heapq.heapify，但可以传给 nlargest
heapq 模块本身不支持带 key 的原地堆化（即没有 heapify(lst, key=...)），但 nlargest 和 nsmallest 支持 key 参数——这是关键区别。
有人试图先用 key 转换数据再堆化，结果发现比较逻辑混乱，因为堆结构只认转换后的值，丢失了原始对象关系。
- ✅ 安全用法：
heapq.nlargest(3, students, key=lambda s: s.gpa) - ❌ 错误尝试：
heapq.heapify([(s.gpa, s) for s in students])后 pop，虽可行但多了一层 tuple 包装，且无法直接拿到原s对象（除非你记得解包） - ⚠️ 注意：
key函数会被多次调用（每个元素至少一次），避免在里面放重操作（如 IO、数据库查询）
性能敏感场景下，要留意内存和重复计算
nlargest/nsmallest 会把所有元素加载进内存，并对每个元素调用一次 key 函数。如果数据来自生成器或文件流，且 n 很小，自己手写一个“维护大小为 n 的堆”的循环反而更省内存。
例如处理百万行日志找响应时间 top 10，用 nlargest(10, log_lines, key=parse_time) 会先把全部行读入内存并解析时间——而逐行解析 + heapreplace 可控内存占用。
- 简版手写逻辑：
heap = []；遍历每行，parsed = parse_time(line)；若len(heap) ，<code>heappush(heap, parsed)；否则if parsed > heap[0]: heapreplace(heap, parsed) - 注意：此时堆里存的是解析后值，不是原始行；若需原始行，得存
(parsed, line)并用key控制比较逻辑 - 这种手写方式绕过了
nlargest的自动策略判断，但换来对内存和计算粒度的完全控制
nlargest 默认返回已排序结果、key 不可用于原地堆化、以及小 n 和大 n 下算法策略的隐式切换。 
