用小顶堆提取top关键词，因需动态维护频次最高的k个词：根节点为当前k中最低频次，新词频次更高时替换根节点并调整，确保堆内始终存最高频k词。
用堆结构提取top关键词，核心是把“词频统计”转化为“找前k个最大值”问题。不排序、不全加载、不依赖外部库，适合处理gb级日志、评论、文档等含大量重复词的文本变量。
为什么选小顶堆而不是大顶堆
目标是保留出现次数最多的K个词，但全程只需维护K个元素的空间。小顶堆的根节点始终是当前K个词里频次最低的那个——一旦新词频次更高，就替换根节点并向下调整。这样能保证堆里永远存着“截至目前见过的频次最高的K个词”。大顶堆做不到这点，它总把最高频的词卡在堆顶，无法快速淘汰低频候选。
关键三步：建堆、流式更新、输出结果
假设你已将文本清洗、分词、统计成词→频次的映射（如哈希表），接下来：
- 建堆阶段：取前K个词频对，按频次构建小顶堆。注意不是按词本身，而是按频次数值建堆；堆中每个节点存的是（词，频次）结构体或指针
-
流式更新阶段：遍历剩余所有词频对。若当前词频 > 堆顶频次，则替换堆顶，并调用
AdjustDown重新维持小顶堆性质。这一步时间复杂度仅为O(log K)，远低于重排整个集合 - 输出阶段：堆中K个元素即为Top K关键词，但顺序无序。如需按频次降序输出，可将堆中元素导出后简单排序（仅K个，代价极小），或在堆内做一次堆排序（升序转降序）
实际编码要注意的细节
直接套用标准堆代码容易翻车：
- 比较逻辑必须基于频次字段，不是字符串字典序。C语言中常通过函数指针传入
compare回调，Java/Python则重写compareTo或用key参数 - 堆数组下标从0开始时，左子节点是
2*i+1，父节点是(i-1)/2——和教材里从1开始的公式不同，写错会导致越界或逻辑错乱 - 内存管理要匹配：如果堆里存的是词字符串指针，确保这些字符串生命周期长于堆；否则需深拷贝或统一用池化管理
- K值不宜过大。当K接近总词种数（比如10万词里取Top 5万），小顶堆优势消失，此时退化为部分排序，建议改用快速选择（QuickSelect）算法
和MapReduce、Spark方案的区别
堆方案是单机内存友好型，适用于：
- 数据源可逐行读取（如日志文件、CSV流）
- 总词种数可控（百万级以内），但每词出现次数极高（如电商搜索词、APP埋点事件）
- 没有Hadoop集群，或只是临时分析脚本
它不替代分布式方案，而是互补：比如先用MapReduce做全局词频统计，再用堆在Reducer端快速截取Top K；或在Flink实时作业中，每个窗口状态用小顶堆维护当前窗口Top K关键词。
