结论：mongodb 8.0 升级需重点验证 $match 前置性、null/undefined 匹配行为变更（{field: null} 不再匹配 undefined）、allowdiskuse 默认启用导致隐式落盘；三者变化易引发查询性能下降或结果偏差。
直接说结论：如果你用的是 MongoDB 8.0，别刻意降级回 7.0；但升级前必须验证 $match 位置、null/undefined 行为、allowDiskUse 默认策略这三处变化。
$match 阶段在管道中的位置影响变大了
MongoDB 8.0 进一步强化了索引下推（index pushdown）逻辑，$match 越靠前，越可能命中索引。7.0 中部分场景还能“侥幸”走索引，8.0 更严格——比如带 $expr 的 $match 如果放在 $group 后，基本不会走索引。
- 7.0 下，
$match放在$sort后有时仍能利用排序字段索引 - 8.0 中，除非明确指定
allowDiskUse: true，否则$sort+$match组合更倾向内存排序，且不触发索引优化 - 实操建议：所有
$match尽量前置，尤其是带时间范围、状态码、ID 等高选择性条件的
null 与 undefined 的匹配行为已变更
这是最隐蔽的坑。MongoDB 8.0 开始，{ name: null } 不再匹配 name: undefined 的文档，而 7.0 会匹配。聚合管道里如果用了 $match 或 $cond 判断字段是否“为空”，结果可能完全不同。
- 7.0 查询
db.users.find({ status: null })会返回status: undefined和status: null的文档 - 8.0 同样查询只返回
status: null，要兼容旧逻辑得显式写成{ $or: [ { status: null }, { status: { $type: "null" } } ] } - 特别注意
$group的_id字段：如果分组键是可能为undefined的字段，8.0 下这些文档会被归入null组，而非单独一组
allowDiskUse 默认行为从 false 变为 true
7.0 需手动传 { allowDiskUse: true } 才能让聚合落盘；8.0 默认启用（前提是配置了 allowDiskUseByDefault: true，Atlas 和新安装的本地实例默认开启）。表面看是省事了，但容易掩盖内存瓶颈。
- 8.0 下，一个原本在 7.0 因内存超限失败的
$group，现在可能默默写临时文件，导致磁盘 I/O 暴涨、延迟飙升 -
$graphLookup仍是例外：无论 7.0 还是 8.0，它都严格限制 100 MB 内存，且忽略allowDiskUse - 实操建议：上线前用
explain("executionStats")查看聚合是否实际用了磁盘，别只看是否成功
真正难处理的不是语法差异，而是那些没报错、结果却不对的 case——比如分组统计少了 2% 的数据，或者某类用户突然查不到订单，根源往往是 null/undefined 匹配变化或 $match 位置失效。升级后第一件事不是跑通，而是拿真实业务数据集做聚合结果比对。
