$merge 能在副本集从节点安全运行是因为其聚合管道由主节点执行写操作，而 MapReduce 始终强制主节点执行且不支持读取偏好。$merge 支持精细策略、分片兼容、详细错误定位及持续增强，MapReduce 已弃用且缺乏优化与运维支持。
$merge 在 MongoDB 6.0 副本集上能安全、可控地写入结果，而 MapReduce 已弃用且不支持从节点读取偏好下的聚合执行。
为什么 $merge 能在副本集从节点上运行，MapReduce 不能
从 MongoDB 5.0 起，只要 featureCompatibilityVersion ≥ 5.0 且客户端使用非 primary 读取偏好（如 secondary 或 nearest），带 $merge 的聚合管道就可在从节点发起——但写操作仍路由到主节点，由主节点完成落盘。这是明确支持的行为。
MapReduce 完全不支持该机制：它始终强制在主节点执行，无论读取偏好如何设置；驱动层也不做从节点分发适配。这意味着在高读低写场景下，MapReduce 会无谓加重主节点负载。
-
$merge阶段本身是声明式、可优化的，MongoDB 查询优化器能介入前序$match、$sort等阶段 - MapReduce 的
map和reduce函数是 JS 字符串，在服务端解析执行，绕过所有索引与执行计划优化 - Atlas M0/Flex 集群直接禁用
mapReduce命令，但允许aggregate+$merge
输出集合存在时，$merge 的行为比 MapReduce 更精细可控
MapReduce 输出逻辑简单粗暴：out: {replace: "target"} 直接删旧建新，out: {reduce: "target"} 则对相同 _id 文档做 JS reduce 合并——但 reduce 函数必须自己处理空值、类型冲突、并发覆盖等问题。
$merge 提供五种明确策略：insert、merge、replace、keepExisting、fail，还能用 on 指定匹配字段（不局限于 _id），甚至用 whenMatched + 自定义 pipeline 做字段级更新（比如只累加计数器，不动时间戳）。
- 例如
whenMatched: [{$set: {count: {$add: ["$count", 1]}}}]，比 MapReduce 里手写if (old.count) old.count += 1更可靠 - 若输出集合已分片，
$merge不会破坏分片键分布；MapReduce 输出为sharded时，强制用_id当分片键，无法自定义 - 出错时
$merge报错信息具体到 stage（如 “duplicate key on field 'user_id'”），MapReduce 常卡在 JS 引擎层，堆栈难定位
部署和排障成本差异远大于语法转换工作量
聚合管道是纯 JSON 结构，可被 mongosh、Compass、BI 工具直接加载或调试；explain("executionStats") 能精确看到每个 stage 的文档数、内存使用、耗时——这对线上慢聚合定位至关重要。
MapReduce 必须传入 JS 字符串，CI/CD 中难以做静态校验，上线后一旦出错，日志里只有模糊的 “JavaScript execution failed”，还得进 mongod 日志翻上下文。
- MongoDB 6.0+ 已将
mapReduce标记为 deprecated，未来版本可能移除；$merge却在持续增强（如 6.0 支持跨库输出、7.0 加入let变量绑定） - 需要动态逻辑时，优先用
$accumulator或$function替代整套 MapReduce，它们受同样执行模型约束，却能复用管道优化能力 - 真正容易被忽略的是：即使你只在本地测试 MapReduce，只要连接的是 Atlas 免费层（M0）或 Flex 集群，命令直接返回
command mapReduce not supported
别纠结“能不能重写”，重点是 $merge 让你不用再为并发写入、分片兼容、错误回滚、监控埋点这些事单独写胶水代码——这些隐性成本，才是 MapReduce 在副本集里最扛不住的地方。
