聚合管道可替代MapReduce，但非无条件替代：90%常规聚合场景用$group、$lookup、$project即可；仅动态键名分组或需JavaScript执行不可表达逻辑（如递归树遍历）才需MapReduce。
能替代，但不是无条件替代——90% 的常规聚合场景用 $group、$lookup、$project 就够了；真正需要 MapReduce 的只剩两类：需动态生成键名的复杂分组，或必须用 JavaScript 执行不可表达逻辑（比如递归树遍历、正则替换后二次解析）。
什么时候聚合管道完全够用
绝大多数统计、关联、过滤、结构重组类任务，聚合管道不仅够用，还更快更稳定：
-
$group支持多字段组合、嵌套表达式（如{$sum: {$multiply: ["$price", "$qty"]}}），无需写 reduce 函数 -
$lookup原生支持左连接，比 MapReduce 里手写 emit + 多集合 join 简洁可靠 - 所有 stage 都可被 MongoDB 查询优化器介入，
$match提前过滤、$sort+$limit能利用索引，MapReduce 完全绕过索引 - 分片集群上，聚合管道自动拆分执行，MapReduce 需手动处理 shard key 分布，容易漏数据
哪些情况仍得退回 MapReduce
不是语法不会写，而是聚合操作符根本无法建模的问题：
- 分组 key 需运行时计算且不固定——比如按“用户最近 3 次订单间隔天数区间”分桶，
$bucket只支持静态边界，而 MapReduce 的 map 函数可任意算出 key 字符串 - 需要在 reduce 阶段做状态累积并跨文档传递中间变量（如滚动平均、路径压缩），聚合管道每个 stage 是无状态的，
$reduce仅限数组内，不能跨文档 - 输入文档结构极度不规则，需 JS 动态解析字段名（例如字段名为
"data_202401"、"data_202402"这种日期编码），$objectToArray能解一部分，但后续聚合仍受限于操作符能力
性能与维护成本的真实差异
别只看执行时间，部署和排障成本更关键：
- 聚合管道语句是纯声明式 JSON，可被 mongosh、Compass、BI 工具直接消费；MapReduce 必须传 JS 字符串，SQL 注入风险高，CI/CD 部署难校验
- 聚合管道错误信息明确（比如
"Unrecognized expression '$xxx'"），MapReduce 报错常卡在 JS 引擎层，堆栈难定位 - MongoDB 6.0+ 已标记
mapReduce为 deprecated，未来版本可能移除；而聚合管道持续新增 stage（如$densify、$merge） - 聚合管道支持
explain("executionStats")查 pipeline 各 stage 耗时，MapReduce 只能看总时间
真正要警惕的不是“该不该用 MapReduce”，而是把本可用 $facet 或 $setWindowFields 解决的问题，硬塞进 MapReduce——那不是灵活，是给自己埋坑。
