$searchMeta 必须紧接 $search 后且无中间阶段，否则失效；其统计结果仅反映 $search 当前输入范围，索引缺失或阶段错乱会导致全表扫描。
全文本搜索在聚合中加 $searchMeta 统计结果本身不慢，但容易因索引缺失、阶段顺序错乱或字段未覆盖导致查询退化为全表扫描——根本问题不在 $searchMeta，而在它前面的 $search 是否真正走上了 Atlas Search 或自管理集群的 text 索引。
为什么 $search + $searchMeta 在聚合里没返回 stats？
常见现象是执行带 $searchMeta 的聚合后，cursor.firstBatch 里没有 searchScore 或 count 字段，甚至报错 "$searchMeta is only allowed after $search"。
-
$searchMeta必须紧跟在$search后面，中间不能插$project、$addFields、$match（哪怕只是过滤非文本字段）等任何 stage - 如果用了
$lookup或$facet包裹$search，$searchMeta就失效——它只认 pipeline 顶层的直接前驱 - 自管理部署下，
$search阶段必须已建好 text 索引；Atlas 集群则需确认是否启用 Atlas Search（不是默认的 text index），否则$search直接报错，$searchMeta根本不会执行
自管理集群中 $searchMeta 返回 count 但极慢？检查索引覆盖
即使 $searchMeta 成功返回了 { count: 1248 }，聚合整体仍卡顿，大概率是 $search 没走索引，而是 fallback 到内存扫描。
- 用
explain("executionStats")查看executionStages：若出现stage: "COLLSCAN"或stage: "TEXT"但nReturned远小于totalDocsExamined，说明 text 索引未生效 - text 索引必须显式创建，且字段名要和
$search中的path完全一致（含嵌套路径如"content.text"） - 聚合中若对
$search结果再做$match（比如{ status: "published" }），这个条件无法下推进 text 索引扫描，MongoDB 会先扫出全部匹配文本的文档，再内存过滤——此时应把status字段也加入 text 索引并设权重，或改用复合索引 +$text查询替代
Atlas Search 下 $searchMeta 的 count 和 facets 性能差异
在 Atlas 集群上，$searchMeta 支持 count 和 facets，但二者成本不同：
-
count: true是轻量级元统计，基本不拖慢主查询，适合分页总数展示 -
facets会触发额外的倒排索引遍历，尤其当 facet 字段基数高（如tags数组含上千种值）时，响应时间可能翻倍；建议对 facet 字段单独建autocomplete或tokenization优化的 search index - 不要在同一个
$search阶段同时开count和多个facets；拆成两个聚合调用更稳：一个只取count，另一个按需拉facets
最易被忽略的一点：$searchMeta 的统计结果只反映 $search 当前输入范围——如果你在 $search 前加了 $match（例如限定时间范围），$searchMeta.count 是该子集内的匹配数，不是全库总数；反过来，如果漏掉前置 $match，$searchMeta 统计的就是全量文本扫描结果，代价可能远超预期。
