MongoDB 嵌入文档字段顺序不同，整体等值查询漏掉记录

MongoDB 文档里明明有相同的嵌套字段和值，用整个对象查询却找不到记录；把查询对象里的两个字段交换位置，又能查到了。这可能来自嵌入文档的整体等值匹配：字段顺序也是匹配条件的一部分。

这里针对普通嵌入文档，例如 profile 是单个对象，而不是对象数组；示例在 mongosh 中使用 find()。如果业务只关心几个字段的值，应按字段路径查询，并确认允许嵌入文档包含其他字段。

整个对象相等与字段值相等不是同一要求

假设测试集合有下面三份文档。这里只展示数据形状，不需要向生产集合插入示例数据：

{ _id: "a", profile: { code: "A7", region: "east" } }
{ _id: "b", profile: { region: "east", code: "A7" } }
{ _id: "c", profile: { code: "A7", region: "east", active: true } }

整体匹配写成：

db.accounts.find(
  { profile: { code: "A7", region: "east" } },
  { _id: 1, profile: 1 }
)

对这组样例，预期只选中 a。b 的嵌入字段顺序不同，c 则多了 active，两者都不满足这个完整对象的等值要求。把 profile 里的条件改写成两个普通属性，并不会自动变成“只比较其中两项”。

如果应用在日志中重新排序了对象键，日志看起来相同也不足以证明实际发送的 BSON 顺序相同。应核对应用构造的查询、驱动序列化所用的数据结构，以及目标文档的完整字段；不要仅凭格式化后的 JSON 截图判断。

按业务需要改成点路径条件

如果要求是“code 与 region 的值相同，字段顺序无关，也允许额外字段”，查询应写成：

db.accounts.find(
  { "profile.code": "A7", "profile.region": "east" },
  { _id: 1, profile: 1 }
)

这两个条件同时成立即可，对上述样例预期选中 a、b、c。带点号的完整字段路径需要加引号；{ profile: { code: "A7" } } 仍是在比较整个 profile，不是只检查 profile.code。

第二个参数只是限制返回哪些字段。把 profile 显示出来，便于确认新增匹配的文档是不是业务真正需要的记录；投影不会改变前面筛选条件的含义。

不能把允许额外字段悄悄带进接口

若业务要求 profile 恰好只有 code 和 region 两个字段，点路径查询会扩大结果范围，不能当作等价替换直接上线。应保留这个额外约束，另行设计与字段结构一致的校验和查询；不要为了让 b 出现而顺带接受 c。

确实需要完整对象相等时，应统一写入与查询的字段构造顺序，并使用驱动支持的有序表示。只排序查询端，不能修正历史数据中不同的字段顺序；也不应在排查时批量重写所有文档。结构约定和历史数据迁移需要单独评估。

本例还要求 profile 为单个对象。如果实际字段是对象数组，多个点路径条件可能由不同数组元素满足，必须另行确认是否需要“同一个元素同时满足”的约束。不要把本文的单对象示例直接推广到数组。

验收要看新增匹配了哪些文档

在脱敏副本上保留顺序相同、顺序交换、含额外字段和字段值不同四类样例。完整对象查询与点路径查询应出现上述可解释的差异；随后把原有租户、权限和状态条件一并加回，比较实际选中的 _id，而非只看总条数变多。

查询方式改变后，原来针对整个嵌入文档的索引也不应被假定与嵌套字段查询具有相同效果。先核对实际查询计划，再决定是否调整索引，不需要通过删除索引来修复匹配语义。

保留原查询代码便于回退。若筛选结果会继续触发更新、通知或计费，应先完成只读范围核对，再恢复后续操作；此次修复本身不要求修改已有文档。