$mergeObjects仅浅层覆盖合并，不累加数值、不递归；正确用法是$group中作为累加器{"$mergeObjects":"$field"}，更新时需管道式$replaceWith配合嵌套$mergeObjects。
聚合中用 $mergeObjects 合并多个文档字段，但结果不对
常见现象是：你用 $group 聚合了一批文档，再用 $mergeObjects 把它们的某个子对象（比如 stats）合并，结果只拿到最后一个文档的值，或字段被意外覆盖、丢失。
根本原因在于：$mergeObjects 不是“求和”或“累加”，它只是按顺序把多个文档对象浅层合并——同名字段直接覆盖，不递归、不累加数值。例如 {"a": 1} 和 {"a": 2} 合并后就是 {"a": 2}，不是 {"a": 3}。
- 若需数值累加（如
savedTowers求和），必须改用$sum或自定义$accumulator，不能依赖$mergeObjects -
$mergeObjects接收的是文档数组，不是单个字段；写成{"$mergeObjects": "$stats"}是错的——$stats是一个数组，但操作符期望的是[doc1, doc2, ...]形式 - 正确写法是
{"$mergeObjects": "$stats"}仅在$group累加器上下文中合法；其他地方必须显式展开，如{"$mergeObjects": ["$stats.0", "$stats.1"]}（不推荐，难维护）
在 $group 阶段里安全使用 $mergeObjects 累加器
这是 $mergeObjects 最稳妥的用法场景：作为 $group 的累加器，合并来自多个输入文档的同结构子对象。
前提是你确认所有输入文档中目标字段（如 profile）类型一致，且你接受“后出现的值覆盖先出现的值”语义（类似 PHP array_merge）。
- 语法必须是
{"$mergeObjects": "$profile"}，不能加方括号，否则报错Invalid $mergeObjects expression - 如果某文档缺失
profile字段，$mergeObjects会跳过它；但如果字段值为null，则会参与合并并覆盖前值 - 分片集群下，必须确保
$group的_id是分片键（或其前缀），否则各 shard 各自 merge，结果不可控
更新文档时用 $mergeObjects 实现嵌套字段深度合并
这不是聚合查询，而是更新操作：你想对已有文档的某个嵌套对象（如 package）做局部合并更新，保留未提及字段，只覆盖/新增传入字段。
必须用聚合管道式更新（MongoDB 4.2+），不能用普通 $set，否则无法避免字段丢失。
- 核心结构是
{"$replaceWith": {"$mergeObjects": ["$$ROOT", {"package": {"$mergeObjects": ["$package", {"parameter": "v2"}]}}]}} -
$$ROOT引用原整个文档；内层$mergeObjects专用于package字段，保证只合并其内部字段 - PHP 驱动中传入动态数据时，确保数组结构与 BSON 兼容（如避免浮点数键、资源类型）
- 误写成
{"$mergeObjects": ["$$ROOT", {"package": {...}}]}会导致整字段替换，丢失package内原有未指定字段
类型冲突导致 $mergeObjects 直接报错
错误信息通常是 cannot merge objects with fields that have different types，比如一个文档里 tags 是数组，另一个是字符串。
$mergeObjects 对类型极其敏感，它不做任何隐式转换。
- 合并前务必统一字段类型：用
$cond+$isArray/$isString做预处理，把字符串转成单元素数组，或过滤掉非法项 - ObjectId 和字符串 ID 混用也会触发该错，需在上游清洗或用
$toString统一 - 遇到
null和缺失字段行为不同：前者参与合并并覆盖，后者被忽略——这容易导致字段“莫名消失”，建议用$ifNull显式补默认空对象
真正难的不是写对语法，而是判断该不该用 $mergeObjects：它只适合结构松散但类型稳定的“补丁式合并”。一旦涉及数值计算、数组拼接或深层递归，就得切到 $reduce、$accumulator 或应用层处理。
