用途：本条目来自 Kotlin 代码陷阱合集，面向使用 Kotlin/JPA、Spring Data 风格 @Query 的后端开发者，用于识别“同一个分组查询被列表和占比统计共用”造成的统计偏差，并给出拆分查询与验证的做法。
主要能力：
- 指出两类消费者需求相反：排行榜只要头部，占比统计需要全体。资料给出两个查询示例，一个带 LIMIT 100 供屏幕列表，一个不带上限供任何要除以总数的计算。
- 说明截断不是近似而是有方向的高估：聚集度 = top5 / total，截掉尾部只减少分母；归一化熵 = H / ln(n)，截尾使 H 下降但 ln(n) 下降更快，比值反而上升。资料给出一组 Zipf 分布 500 实体的样例数据（无上限：total 10182，concentration 0.423，diversity 0.689；LIMIT 100：total 8505，concentration 0.506，diversity 0.748）。
- 指出被截断的结果没有任何提示，恰好返回 LIMIT 行且无错误，可通过与同一窗口的 COUNT(DISTINCT …) 对比来判断，结果行数恰好等于上限时应视为未验证。
- 解释复用发生的机制：统计需要 (id, count)，而方法签名恰好匹配、已限定时间窗口、已在数据源上，截断藏在另一模块的字符串常量里，调用点看不出上限存在。
- 说明无上限查询的 ORDER BY 承担关键作用：聚集度按 counts.take(5).sum() 做位置读取，删掉排序会让“top-5 占比”悄悄变成“某 5 个的占比”，仍落在 0..1 内却错误；应保留排序并在查询处注明原因，或让消费方自行排序。
- 强调无上限只有在分组键限制行数时才安全：GROUP BY entityId 每个不同实体至多一行，属于数据事实而非查询事实，应写明预期量级并在窗口可能扩大时复查；对高基数键做无上限 GROUP BY 是另一种决策。
- 指出占比查询通常不需要 id，只消费计数；同时投影键虽无害，却正是让两个查询看起来可互换的原因。
- 提醒把 LIMIT 100 调大到 LIMIT 10000 仍是上限，只是让错误变小、在测试数据上无法复现，并仅对新上限以下的用户正确，而这恰是无人排查的用户群。资料还指出同类模式出现在：带上限的列表连接后算百分比、分页读取求和成总数、用“top tags”查询算覆盖率；凡是数字要除以某值，都应追溯到查询并检查上限。
使用方式：资料给出验证步骤。先用 grep 在 .kt 文件中查找带 LIMIT 的分组查询（注释在函数前，函数名在 LIMIT 之下，-A 2 使名称出现在输出中）：grep -rn --include='.kt' -B 6 -A 2 "LIMIT 100" . | grep -v '/build/' | grep -E "GROUP BY|LIMIT|suspend fun"。再查找除以由带上限结果得出的总数的消费者：grep -rn --include='.kt' -E ".take([0-9]+)|.sum()" . | grep -v '/build/'，其中 .take(n) 也属于上述位置依赖，需确认源查询的 ORDER BY 是有意为之。最后可用只读、无需数据库的 Python 片段在自有分布上复现：python3 -c "import math; counts = sorted([max(1,int(2000/(r**1.1))) for r in range(1,501)], reverse=True); def s(c): t=sum(c); return sum(c[:5])/t, (-sum((x/t)*math.log(x/t) for x in c))/math.log(len(c))); print('unbounded %.3f %.3f' % s(counts)); print('capped %.3f %.3f' % s(counts[:100]))"，把合成计数换成某一窗口的真实导出；若两行结果一致，只说明该时段尾部足够短，并不代表可以复用查询。
适用场景：Kotlin 后端中基于分组计数生成排行榜、计算头部占比、多样性/熵、覆盖率等需要与总数相除的统计；代码审查中检查带 LIMIT 的分组查询及其消费者。
限制：资料是该陷阱的分析与示例，未提供安装命令、包名、发布形态或平台支持信息，这些事实暂未提供；验证方法依赖现有 Kotlin 代码库与可选的真实数据导出。