$topn 不能替代 sort().limit(10)，因其仅在 $group 内生效，专用于“每组内 top n”，非“全局 top n”；无分组时语法非法，强行用 {_id: null} 会触发内存超限错误。
$topN 和 $bottomN 是 MongoDB 5.2 引入的聚合阶段专用累加器，不是替代 sort() + limit() 的通用方案——它们只在 $group 内部生效，且必须配合明确的分组上下文使用。直接用它做“全集合取前10”会报错或逻辑错位。
为什么不能用 $topN 替代 sort().limit(10)
常见误解是把 $topN 当成 ORDER BY ... LIMIT 的等价物。但它本质是「每组内 Top N」，不是「全局 Top N」。没有 $group 阶段时，$topN 语法非法；强行包裹空 _id 分组（如 {_id: null}）虽能跑通，但会强制全量加载进内存再裁剪，触发 100MB 单组限制报错（errmsg: "Exceeded memory limit for $group, but didn't allow external sort"）。
-
$topN必须嵌套在$group的字段值中，例如{ playerId: { $topN: { ... } } } - 若想实现「全集合最高分用户」，应优先走索引优化的
find().sort().limit()，而非硬套$topN -
$topN不支持在$project或$addFields中作为表达式使用，文档明确标注「not supported as aggregation expression」
$topN 真正适用的场景：按业务维度分组后取每组 Top N
典型用例是「每个游戏里得分最高的 3 名玩家」或「每个城市销售额前 5 的门店」。这时 $topN 能避免手写子查询或应用层二次聚合，且天然支持 output 字段定制（比如同时返回 playerId 和 score）。
-
n参数可为常量（如3）或依赖_id的表达式（如{ $cond: [ { $eq: [ "$_id", "G1" ] }, 5, 3 ] }），但不能引用其他字段 -
sortBy字段必须是$group输入文档中存在的字段，不支持表达式（如{ $sum: ["$a", "$b"] }） - 当分组内含缺失字段（如
score不存在）或null值时，$topN默认将其转为null并参与排序——BSON 类型规则下，null排在最前（升序）或最后（降序），需用多字段sortBy显式破歧，例如{ score: -1, playerId: 1 }
和索引加速的 sort() + limit() 对比：性能与语义差异
二者解决的是不同层级的问题：sort() + limit() 是「单次查询结果截断」，靠复合索引跳过排序；$topN 是「分组内局部聚合」，不依赖索引，但受内存和分组粒度制约。
- 高频接口如「首页推荐榜」建议用
find({status: "active"}).sort({score: -1}).limit(10)+ 覆盖索引{status: 1, score: -1}，响应稳定 - 离线统计如「每个品类下销量 Top 3 商品」适合
$topN，因分组键（category）天然分散数据，单组不会超 100MB 限制 - 注意
$topN输出是数组（如[["A", 99], ["B", 95]]），而sort()+limit()返回扁平文档流，下游处理逻辑需适配
真正容易被忽略的点是：当你在聚合管道里已经用了 $lookup 或 $unwind，再加 $topN 就失去了索引优势，此时不如把 Top N 逻辑拆到应用层——MongoDB 的累加器不是万能加速器，而是特定分组语义下的语法糖。
