Top K算法工程实践：堆、快速选择与海量数据分片聚合

排行榜、热搜榜单、耗时最长的慢查询、点赞数最高的评论……只要系统里存在"排序"这个动作，Top K 算法分析就早晚会摆到你的桌面上。我见过不少团队在这个看起来一句话就能打发的需求上翻车：数据量小的时候一句全排序跑得飞快，数据涨到千万级以后接口直接超时；有人求前 K 大却用了大顶堆，取出来恰好是后 K 个；还有人把 K 当成常量写死在代码里，业务方第二天要 Top 100，只能改代码重新发布。这篇内容不打算背课本，把 Top K 当成一个真实的工程问题来拆：什么规模的 N 配什么算法，堆、快速选择、计数桶各自的舒适区和雷区在哪，海量数据怎么分片聚合，流式榜单怎么处理时间衰减，以及那些踩过才知道的细节。

1. 先把问题问对：Top K 到底在问什么

动手写代码之前，我习惯先跟提需求的人确认三件事，问不清楚后面全是返工。第一件是"数据在哪"——是内存里现成的一个数组，还是躺在几十个分片上的历史流水，还是要边产生边出结果。第二件是"K 有多大"——K=10 和 K=100000 完全是两套方案，前者堆能扛，后者堆和快选都不划算。第三件是"要多准"——精确 Top K 和近似 Top K 的成本差一个数量级，很多业务其实容忍千分之几的误差。这三件事定下来，算法基本上就只剩一两个可选项了，剩下的全是工程细节。

1.1 三个典型场景，需求差别大得离谱

榜单类（热榜、销量榜、积分榜）。特点是 N 中等（几十万到几千万条候选），K 很小（20 到 100），但要求高频刷新，通常还要求去重、支持时间衰减、支持按维度分组。这类场景真正的难点不在算法，而在数据实时性和榜单的稳定性——相邻两次刷新榜单大幅跳动，用户体验会很差，所以往往要加平滑或者加最小展示时长。

离线统计类（一天的日志里耗时最长的 20 个接口、异常最多的 50 个用户）。特点是 N 极大（十亿级），K 极小，允许分钟级甚至小时级延迟，但要求结果精确、可复核。这类场景堆完全够用，重点是分片和归并，以及数据倾斜的处理。

服务内实时计算类（一次请求里从 5000 个候选商品中挑 10 个）。特点是 N 小、K 小、延迟敏感，要求亚毫秒。这类场景其实没什么算法讲究，直接堆或者干脆排序都行，反而要小心的是对象分配和 GC 抖动。

三类场景放到一起看就很清楚了：算法选择不是由"谁更优雅"决定的，而是由 N 的量级、K 的量级、内存上限、精度要求四个约束共同决定的。下面所有的方案都是在为这四条约束做权衡。

1.2 三条硬约束：N、K、内存上限

先算内存，这是最容易被忽略的一条。假设你要从 1 亿条记录里取 Top 1000，原始数据全量加载：每条记录如果是一个 8 字节的整数，光数据就是 800MB，加上语言层的对象头和容器开销，Python 里这个数字能翻三到五倍，直接就是几个 G。而如果只用堆，堆里常驻的元素永远只有 K 个，1000 个元素连 100KB 都不到。这两种做法的内存差距是四个数量级，这就是为什么"数据量一大就必须换思路"，不是因为慢，是因为装不下。

时间上的账也要提前算。堆的复杂度是 O(N log K)，K=1000 时 log₂K≈10，1 亿条数据就是 10 亿次比较量级。快速选择的平均复杂度是 O(N)，理论上快一个数量级，但常数因子更大、实现更容易出错。全排序是 O(N log N)，1 亿条大约 27 亿次比较，而且还要额外 O(N) 空间，在大多数场景里属于"能跑但不该用"的选项。

还有一条隐形的约束：K 是否固定。K 固定且小，堆是首选；K 接近 N（比如取前 80%），快速选择更合适；K 需要动态变化，那得考虑数据结构本身是否支持增量维护，而不是每次重算。

2. 方案选型：五种解法的舒适区与雷区

2.1 全排序：最省事，也最容易被骂

sort()然后切前 K 个，这是绝大多数人的第一版实现，我不觉得它丢人。N 在十万以内、调用频率不高的时候，排序的实现在语言标准库里被优化到了极致，实际表现往往比手写的堆更好——因为标准库的排序是混合策略，小数组用插入排序，大数组用归并或内省排序，缓存友好度远高于你在 Python 层面写的循环。我实测过 10 万个随机整数取 Top 10，Python 的sorted()反而比heapq.nlargest()还快一点，原因是 C 层实现的开销更小。

但它的雷区也很明确。第一是空间，很多排序实现需要 O(N) 的额外空间，数据量上去之后内存直接爆掉。第二是不能流式，数据必须全部拿到才能开始排，而流式场景下你根本不知道下一条数据什么时候来。第三是重复计算，如果榜单需要每秒钟刷新一次，每次全排序就是每秒一次 O(N log N) 的浪费，而堆可以做到增量维护。

我的判断标准很粗暴：数据能一次性放进内存且 N 不超过一百万，就直接排序，别搞花活。超过这个量级，或者有明显的实时性要求，再往堆和快选上走。过早优化带来的调试成本，往往比那点性能收益贵得多。

2.2 小顶堆：求前 K 大的标准答案

求前 K 大用小顶堆（堆顶是最小值），这个方向很多人第一次写会搞反。理解方式很简单：堆里始终保存着"目前见过的最大 K 个数"，那么堆顶就是这 K 个里最小的那个，也就是"进入 Top K 的门槛"。新来的数只要比门槛大，就说明它配得上进榜，把门槛踢掉、自己进去，堆自动调整出新门槛。如果新来的数比门槛小，连门槛都过不了，直接丢弃，连入堆都不用。

这个"先比堆顶再决定要不要操作"的细节很关键。新手常写的是无脑push然后pop，每次都要做两次堆调整；先比较再replace，绝大多数的数据只需要一次比较就被丢弃了，实际耗时能差出两到三成。

import heapq def topk_largest(items, k): if k <= 0: return [] heap = [] # 小顶堆，堆顶是当前 Top K 的最小值 for x in items: if len(heap) < k: heapq.heappush(heap, x) elif x > heap[0]: # 先比门槛，比不过直接跳过 heapq.heapreplace(heap, x) return sorted(heap, reverse=True)

复杂度是 O(N log K)，额外空间 O(K)。K=10 时 log K 只有 3.3，几乎等同于线性扫描，这就是它比排序快的原因——排序对所有 N 个元素都做了完整排序，而堆只关心 K 个位置。

它的短板有两个。一是 K 大时优势消失：K=10 万、N=100 万时，log K≈17，堆的总操作量接近全排序，还要额外维护堆结构，反而不如直接排序。二是不能随机访问：堆只能给你 Top K 这个集合，给不了"第 5 名是谁"这种有序访问，要排序输出就得再排一次，这一步很多人忘了算成本。

提示：如果元素是元组（分数, id）这种复合结构，Python 的堆在分数相同时会继续比较第二个字段。一旦第二个字段是None或者不可比较的类型，就会抛TypeError，这个报错在线上出现的频率比想象中高得多。

2.3 快速选择：平均线性的诱惑与深坑

快速选择（Quickselect）借用了快排的分区思想：随机选一个基准值把数组分成"比它大的"和"比它小的"两部分，看较大那部分的长度和 K 的关系，只递归处理其中一边。因为每次只处理一半，总工作量是 N + N/2 + N/4 + …，收敛到 2N，所以平均复杂度是 O(N)，而且不需要额外空间。

import random def quickselect_kth_largest(nums, k): """返回第 k 大的值（k 从 1 开始），原地修改 nums""" target = len(nums) - k # 转成"第 target 小的下标" lo, hi = 0, len(nums) - 1 while lo < hi: pivot = nums[random.randint(lo, hi)] # 三路划分：大于 pivot / 等于 pivot / 小于 pivot i, lt, gt = lo, lo, hi while i <= gt: if nums[i] > pivot: nums[lt], nums[i] = nums[i], nums[lt] lt += 1 i += 1 elif nums[i] < pivot: nums[gt], nums[i] = nums[i], nums[gt] gt -= 1 else: i += 1 if target < lt: hi = lt - 1 elif target > gt: lo = gt + 1 else: return nums[target] return nums[lo]

上面这段用的是三路划分，把等于基准值的元素集中到中间，这一步是抗退化的关键。如果只用两路划分，遇到大量重复值（比如几百万条记录的分数都是 0）会退化成 O(N²)，因为每次划分只能排除掉极少数元素。我见过一个真实案例：某个统计任务在测试环境跑 200 毫秒，上线后跑了 40 分钟，原因就是线上数据里 90% 的分数是同一个值，两路划分每次都只能砍掉一个元素。

另一个坑是基准值的选择。如果固定选首元素或尾元素，遇到已经有序的输入同样会退化。随机选或者三数取中（median-of-three）都能缓解，但随机数本身也有开销，高频调用的小数组场景下这个开销不可忽略。理论上还有 BFPRT 算法可以做到最坏 O(N)，但常数因子大，工程上极少用，我不建议在生产代码里上这个东西。

快速选择的适用边界：K 和 N 同量级、数据在内存里、允许打乱原数组、只关心"第 K 名是谁"而不关心 Top K 的内部顺序。如果这四个条件有一个不满足，堆更稳。

2.4 计数与桶：数据范围可控时的降维打击

如果打分范围是固定的（比如 0 到 100 的评分、0 到 5 的星级、有限的几个状态码），那根本不需要比较，直接开数组计数就行。统计每个值出现多少次，然后从高到低累加，累加到 K 就停。复杂度 O(N + M)，M 是值域大小，比任何基于比较的算法都快，而且天然处理重复值、天然有序。

def topk_by_count(scores, k): buckets = [0] * 101 # 假设分数 0-100 for s in scores: buckets[s] += 1 result, remain = [], k for value in range(100, -1, -1): if buckets[value] == 0: continue take = min(buckets[value], remain) result.extend([value] * take) remain -= take if remain == 0: break return result

桶排序是计数排序的推广：值域太大没法开数组时，按范围切分成若干桶，把数据散进桶里，然后只对"可能有 Top K"的那几个高分段桶做精细处理。这里有个很实用的技巧——先扫一遍统计每个桶的元素个数，从高分段往低累加，找到第 K 名落在哪个桶，然后只对这个桶做堆或排序。这样绝大多数数据只需要一次简单的除法定位，连比较都不需要。

实际应用里最典型的是"按分数段统计"和"按哈希分桶做分组 Top K"。比如要统计每个用户的 Top 10 消费记录，可以按 user_id 哈希分桶，同一个用户的数据必然落进同一个桶，桶内单独维护堆，内存是 O(桶数 × K)，比维护一个巨大的全局结构省得多。

注意：桶排序的效果完全取决于数据分布的均匀程度。如果数据严重倾斜（比如 95% 落在一个桶里），它就退化成了对单个桶做全排序。上线前一定要先采样看一下分布，别凭直觉假设。

2.5 概率结构：近似 Top K 什么时候能接受

数据流大到连"过一遍"都嫌贵的时候，精确算法就没意义了，这时候要考虑近似结构。Space-Saving是最常用的一个：维护 m 个计数器槽位，新元素来了如果已有槽位就加一，没有就替换掉当前计数最小的槽位并把它的计数加一作为新元素的起始计数。它的保证是：任何真实出现频次超过 N/m 的元素一定能被找到，且估计值只会偏大不会偏小。内存恒定，跟数据总量无关。

还有一类是配合计数草图（Count-Min Sketch）用的：草图负责给出每个元素的频次估计，再在外面套一个大小为 K 的堆维护候选集。这种方式适合"数据量极大但只需要知道大致排名"的场景，比如粗粒度的热门内容发现、异常 IP 的初步筛选。

我的态度比较保守：只要业务方能看到具体数字，就别用近似算法，除非你能明确告诉他们误差范围并被接受。榜单这种用户直接可见的东西，第 7 名和第 8 名因为误差换了位置，用户是会来投诉的。近似结构更适合做内部筛选的第一道漏斗，筛出候选集之后再精确计算。

3. 手把手实现：从单机堆到分片聚合

3.1 Python 版本：参数推导与常见写法

先看参数。假设 N=5000 万条订单记录，要取金额最大的 100 笔。每条记录在内存里如果加载成字典，大概 300 到 500 字节，全量就是 15 到 25GB，单机内存扛不住。改成流式读取 + 大小为 100 的堆，常驻内存 100 个元组，每个约 150 字节（Python 的 tuple 加两个 int 对象，实际开销比想象中大），总共十几 KB。

读取方式上，我强烈建议用生成器而不是先list()再处理：

def read_records(path): with open(path, encoding="utf-8") as f: for line in f: yield parse_line(line) # 逐行解析，内存恒定 def topk_stream(gen, k, key=lambda x: x[0]): heap = [] for item in gen: score = key(item) if len(heap) < k: heapq.heappush(heap, (score, item)) elif score > heap[0][0]: heapq.heapreplace(heap, (score, item)) return [item for _, item in sorted(heap, key=lambda t: t[0], reverse=True)]

这里有个细节值得展开：为什么把score放在元组第一位，而不是直接比较 item？因为堆需要可比较的对象，如果 item 是字典或者自定义对象，Python 3 会直接报"不可比较"错误。把分数提到第一位，绝大多数情况下比较到分数就结束了，只有在分数相同时才会去比较 item，这时候如果 item 不可比较，照样会炸。稳妥做法是在元组第二位放一个唯一的、可比较的 id，位次放在最后。

还有一个容易被忽略的点：不要用heapq.nlargest(k, iterable)处理超大流。这个函数内部确实也是维护一个小顶堆，看起来很合适，但它返回结果时会做一次完整排序，而且对 k 较大时（官方文档说的是 k 接近 n 的情况）会自动切换到直接排序，内存会瞬间飙上去。数据量不确定的时候，老老实实自己写循环更可控。

3.2 C++ 与 Java：比较器的方向问题

跨语言实现 Top K，最容易错的地方不是算法，是比较器的方向。C++ 的priority_queue默认是大顶堆，要求前 K 大就得显式传greater；Java 的PriorityQueue默认是小顶堆，反而不用改。这两个语言的方向正好相反，来回切换的时候非常容易写错。

// C++：求前 K 大，用小顶堆 std::priority_queue<int, std::vector<int>, std::greater<int>> min_heap; for (int x : nums) { if ((int)min_heap.size() < k) { min_heap.push(x); } else if (x > min_heap.top()) { min_heap.pop(); min_heap.push(x); } }

// Java：PriorityQueue 默认就是小顶堆，求前 K 大直接用 PriorityQueue<Integer> pq = new PriorityQueue<>(k); for (int x : nums) { if (pq.size() < k) { pq.offer(x); } else if (x > pq.peek()) { pq.poll(); pq.offer(x); } }

Java 这边有个内存上的小坑：new PriorityQueue<>(k)里的 k 是初始容量，不是上限。堆会随着offer自动扩容，写成 0 或者负数会直接抛异常，写成 1 虽然不报错但会反复扩容。按 K 来初始化容量是最省事的做法。

C++ 还有一个很实用的替代方案：std::nth_element。它底层就是快速选择，一次调用就能把第 K 大的元素放到正确位置，前面全是比它大的，后面全是比它小的。代码只有一行，性能也比手写快选稳：

std::nth_element(nums.begin(), nums.begin() + k - 1, nums.end(), std::greater<int>()); // 此时 nums[0..k-1] 就是前 k 大（内部无序）

需要提醒的是nth_element会原地打乱数组，如果原数组后续还要用，记得先拷贝。这个拷贝的成本是 O(N)，有时候反而成了瓶颈，所以到底用不用，得看你更在意代码量还是内存。

3.3 海量数据：分片 + 局部 Top K + 全局归并

单机内存装不下的时候，唯一的路就是"分而治之"。核心思路是把 N 条数据切成 M 片，每片单独算局部 Top K，最后把 M×K 个候选归并出全局 Top K。正确性是有保证的：全局第 K 大的元素，在它所在的那一片里，排名不可能超过 K，所以一定会被该片的局部 Top K 捕获。

具体怎么分片有讲究。按行顺序切分最简单（前 100 万行一片），缺点是如果数据本身有序（比如按时间写入的日志），某一片可能全是小值，另一片全是候选，导致数据倾斜。按哈希分片（hash(key) % M）分布更均匀，而且有一个额外好处：同一个 key 的数据必然落在同一片，如果需求是"每个用户取 Top K"，哈希分片天然支持分组，不会出现同一个用户的数据被切到两个片的情况。

import hashlib def shard_of(key, m): h = hashlib.md5(str(key).encode()).hexdigest() return int(h, 16) % m def map_phase(records, m, k): shards = [ [] for _ in range(m) ] # 实际场景应写入临时文件 for r in records: shards[shard_of(r["user_id"], m)].append(r) local = [] for s in shards: local.append(topk_stream(iter(s), k, key=lambda x: x["amount"])) return local def reduce_phase(local_results, k, key=lambda x: x["amount"]): merged = [item for part in local_results for item in part] return topk_stream(iter(merged), k, key=key)

归并阶段的元素数量是 M×K，如果 M=1000、K=100，就是 10 万个元素，堆处理起来毫无压力，这一步基本不构成瓶颈。真正决定整体耗时的是 Map 阶段每个分片的扫描速度，所以优化的重点应该放在 IO 和解析上，而不是算法本身。

分片数量怎么定？我的经验是让每片的数据量落在几十万到几百万之间。片太小，任务调度和文件打开关闭的开销占比过高；片太大，单点失败重试的成本太高。M=1000 片、N=10 亿的话，每片 100 万条，正好在舒适区。另外分片任务最好能并行执行，单机多进程或者多机调度都行，但要注意别让输出文件和输入文件落在同一块盘上，IO 争抢会吃掉并行带来的收益。

3.4 流式榜单：滑动窗口与时间衰减

前面的方案都假设数据是"批"的，而真实榜单往往是"流"的——用户每点一次赞都要实时反映到榜单上。这时候堆就不合适了，因为数据会过期，而堆删不掉任意元素（只能删堆顶）。常见做法是换个数据结构。

窗口型需求（最近 1 小时的热门内容）用有序集合最顺手：成员是内容 id，分值存时间戳，新事件进来就写入，同时定期把超出窗口范围的成员清掉，取 Top K 就是反向取前 K 个。清理动作可以放在每次写入时顺手做，也可以起一个定时任务做，前者实时性好但增加写延迟，后者吞吐高但有延迟，看业务能接受哪个。

累计型榜单（总热度榜）用带时间衰减的打分公式更合理。纯累计分数会让老内容永远霸榜，新内容没有出头机会，所以要在分数里加入时间因子。一个我常用的形式：

score = log10(点赞数 + 1) + (发布时间戳 - 基准时间) / 45000

前面取对数是为了压制头部内容的绝对优势——1 万赞和 100 万赞在对数下只差两倍，不至于让差距被无限放大；后面的线性项是新鲜度加成，除数决定了"多长时间能抵消一个数量级的差距"，除以 45000 大致相当于每 12.5 小时补足 1 分，一天能补将近 2 分，也就是一条新内容一天内能追上点赞数差 100 倍的老内容。这个参数没有标准答案，得根据业务的内容更新频率去调，调的时候建议直接拉一周的真实数据跑个回放看看榜单长什么样，比拍脑袋靠谱。

分组 Top K 也是常见需求（每个类目各取前 10）。做法是用一个字典把类目映射到各自的堆，内存是 O(类目数 × K)。这里要小心类目数量不可控的情况——如果类目是用户自定义标签，可能有几十万个，内存就会爆。这时候要么限制只统计高频类目，要么退化成"先做一次类目频次统计，再对 Top 级类目单独算"。

4. 常见问题与排查实录

4.1 方向写反、边界越界、重复值

堆方向写反是最高频的问题，症状也很典型：求前 K 大取出来的是后 K 个，或者结果整体看起来"反了"。判断方法很简单，问自己一句"堆顶应该是什么"——堆顶是当前 Top K 里最容易被淘汰的那个，求前 K 大时最容易被淘汰的是最小值，所以堆顶必须是当前最小值，也就是小顶堆。反过来求前 K 小就用大顶堆。这个推导过程比死记硬背可靠。

边界条件上，K 大于 N 的时候直接返回全部，不用特殊处理但要确认代码不会越界；K=0 或负数要提前拦掉，很多实现会在这里抛异常；N=0 时返回空集合。还有一种隐蔽情况：数据里有None、NaN或者空字符串。NaN的比较行为很特殊，它和任何值比较都返回False，会导致它在堆里"卡住"——既不比门槛大也不比门槛小，行为完全不可预测。上线前一定要先做一次空值和异常值过滤，这一条我吃过亏。

重复值在两种算法里表现完全不同。堆对重复值天然友好，因为比较的是数值，相等就走"比不过门槛"的分支被丢弃。快速选择就麻烦得多，前面说过的两路划分退化问题就是重复值引起的。还有一点：如果业务要求"Top K 里不能有重复的用户"，那算法本身解决不了，得在入口处去重，用一个集合记录已见 id，代价是内存 O(N)。这个集合的成本经常被低估，几千万个 id 的集合在 Java 里能吃掉好几个 G。

4.2 性能不达预期时的排查路径

堆的复杂度是 O(N log K)，理论上不该慢。实测慢的时候，我一般按这个顺序排查。

第一步看 K 是不是被设大了。有过一个案例，业务方要"前 1000 名"，代码写的 K=1000，看起来没问题，但那是个每秒调用上千次的高频接口，每次都要维护一个 1000 大小的堆，log K≈10，比 K=10 时慢了三倍多。后来改成先用阈值做一次粗筛（只保留分数超过某个固定值的候选，通常只有几千条），再对小候选集排序，耗时直接降了一个数量级。

第二步看比较操作的代价。堆的操作里比较是重头戏，如果比较的是长字符串或者需要反序列化的复杂对象，每次比较的成本可能比堆操作本身还高。优化方式是提前算好一个数值型的分值参与比较，把昂贵的比较挪到数据准备阶段。

第三步看数据源。很多"算法慢"的问题最后查出来是 IO 慢——逐行读文件、逐条查数据库、逐条调接口，算法部分只占 5% 的时间。这种情况下优化算法纯属浪费精力，该做的是批量读、预取、并行化。

第四步看内存和 GC。Python 里创建大量临时对象会触发频繁的垃圾回收，Java 里堆扩容会触发 full GC，表现出来都是"跑着跑着突然卡一下"。解决方法是复用容器、避免在循环里创建对象、给容器预设容量。

4.3 常见问题速查表

5. 实测数据与工程取舍

5.1 各方案在不同规模下的表现

我在一台 8 核 16G 的机器上跑过一组对比，数据是随机生成的整数，Python 3.11，各跑五次取中位数。这些数字不能当成绝对标准，但相对关系是稳定的，选型时可以参考。

几个观察值得说说。N 小的时候排序赢，这个前面提过，因为标准库的 C 实现常数太小了，手写的 Python 循环根本不是对手。N 上到百万级之后堆开始反超，但优势没有理论复杂度显示的那么夸张，因为 Python 层面的循环开销吃掉了不少算法红利。快速选择在 K 小的时候比堆还快，这跟理论预期不太一致——原因是快选只需要一次扫描加少量划分，堆则要做 N 次堆调整，K 小时两者的差异主要来自常数因子。但当 K 涨到 N/2，快选的优势就变得非常明显了，因为这时候堆的 log K 已经接近 log N。

还有一个反直觉的点：分片 100 份跑 1 亿条数据的总耗时，反而比单进程处理 1000 万条的四倍还少。原因是分片之后 IO 和计算能重叠，多个进程并行读不同的文件块，磁盘利用率上去了。这说明数据量到一定规模之后，并行度的收益比算法优化大得多，方向别搞错。

5.2 我踩过的几个坑

第一个坑是用list.sort()之后切片，但忘了原数组被修改。有一段代码里，排序结果被下游拿去当"原始顺序"用，结果全乱了。这种问题排查起来特别费劲，因为错误现场离出错位置很远。后来我养成的习惯是，凡是要排序或做快选的数组，如果调用方还持有引用，一律先copy()一份，宁可多花点内存。

第二个坑是K 的语义没对齐。业务说的"前 10 名"有时候是"前 10 条记录"，有时候是"前 10 个用户"。如果同一个用户有多条记录，两种理解的结果完全不同。这个歧义在需求评审时一定要问清楚，别自己猜。

第三个坑是时间衰减参数上线前没做回放验证。第一次调的时候我把新鲜度系数设得偏大，结果上线后榜单基本只展示最近两小时的内容，老内容无论多热门都上不去，运营那边直接炸了。后来改成先拿一周历史数据做离线回放，把每个小时的榜单打出来人工看一遍，确认排序符合直觉了才上线。这个流程现在是我的标配，任何涉及排序权重的改动都必须过一遍回放。

第四个坑是分布式归并时忘了处理空分片。有些分片因为数据倾斜实际是空的，topk_stream返回空列表，归并阶段拼起来没问题，但后续有个地方直接取了result[0]做展示，空列表就崩了。分布式场景下"某个分片没数据"是常态，所有归并后的结果都要当可能为空来处理。

第五个坑说起来有点蠢：在循环里反复创建堆对象。有个定时任务每分钟跑一次，每次都要从数据库拉数据算 Top 100，代码写成每次新建一个 list 当堆。数据量不大的时候看不出来，后来候选集涨到几十万条，每分钟都在制造几十万个临时对象，GC 压力肉眼可见。改成复用容器、每次clear()之后，CPU 占用降了将近一半。

最后分享一个判断上的经验：Top K 这类问题的性能瓶颈，九成不在算法本身，而在数据怎么进来、结果怎么出去。我现在的习惯是先写一版最笨的实现（全排序或者直接堆），把链路跑通，测出端到端耗时，看看算法部分占多少比例。如果占比不到两成，那优化算法就是自我感动；只有当算法确实成为主要成本时，才值得去抠快选的三路划分或者堆的比较器细节。这个顺序反了，很容易在错误的地方投入大量时间。