$project 提前终止索引下推的主因是改变字段可用性而非阻断索引：排除、重命名或计算索引字段均导致后续$match无法复用索引；仅保留原始字段（如{_id:0,name:1}）或添加新字段不影响索引下推。
$project 会提前终止索引下推的常见原因
不是 $project 本身“阻断”索引，而是它改变了文档结构和字段可用性，导致后续 $match 阶段无法复用集合层的索引。MongoDB 的查询优化器只在**输入文档仍保留原始索引字段且未被投影掉**时，才可能把 $match 下推到索引扫描阶段。
- 如果
$project显式排除了索引字段（比如{"status": 0}），而后续$match又要用{status: "active"}过滤——这个条件就再也触碰不到索引了 - 如果
$project重命名了索引字段（比如{"state": "$status"}），那$match: {state: "active"}就是全新字段，索引无效 - 如果
$project计算新字段（比如{"score": {$add: ["$a", "$b"]}}），后续基于score的$match必然走内存过滤，不可能下推
哪些 $project 写法还能保索引
只要不破坏原始字段的可访问性，$project 就不会切断索引链路。关键看字段是否“原样保留”或“显式包含”。
- 只抑制
_id：{$project: {_id: 0, name: 1, email: 1}}→ 后续$match: {name: "x"}仍可用name索引 - 添加新字段但不删/改旧字段：
{$project: {name: 1, email: 1, fullName: {$concat: ["$firstName", " ", "$lastName"]}}}→$match: {email: "x"}不受影响 - 用
$$REMOVE条件排除字段（而非硬写0）→ 字段路径依然存在，优化器能识别潜在索引字段
实际调试时怎么确认索引是否生效
别猜，直接看执行计划。对聚合管道加 .explain("executionStats")，重点盯两个字段：
-
executionStats.totalKeysExamined：接近totalDocsExamined？说明没走索引；远小于后者？说明命中了 -
executionStages.stage中是否出现IXSCAN（不是COLLSCAN） - 特别注意：如果 pipeline 里有多个
$match，执行计划会显示每个$match是独立下推还是合并处理
最容易被忽略的陷阱：$project + $facet 或 $lookup 后的 $match
一旦 $project 出现在 $facet 内部或 $lookup 的子管道中，它的作用域就局限在那个分支里。外部 $match 完全看不到原始集合字段——此时索引失效不是因为 $project 本身，而是因为数据已经脱离原始文档上下文。
真正要小心的，从来不是 $project 该不该用，而是它让哪些字段“在后续阶段里不可见”了。
