$eq 是 mongodb 中精确匹配整个数组（含顺序、长度、元素内容）的唯一正确方式，{ tags: { $eq: ["a", "b", "c"] } } 仅匹配完全一致的数组，支持嵌套对象且对象键序无关，可走多键索引。
用 $eq 直接匹配整个数组（含顺序）
MongoDB 默认对数组字段做「包含匹配」，比如 { tags: "mongodb" } 会命中 ["node", "mongodb", "dev"] —— 这不是你想要的「精确顺序」。要完全一致，必须把整个数组当做一个值来比，而不是展开查元素。$eq 是最直接、最安全的方式，它要求字段值在类型、长度、每个元素位置和内容上都完全相同。
- ✅ 正确写法：
{ tags: { $eq: ["a", "b", "c"] } }—— 匹配["a", "b", "c"]，不匹配["a", "c", "b"]或["a", "b"] - ⚠️ 别用
$all：它只保证「所有元素存在」，不管顺序、不防重复、不限长度，{ tags: { $all: ["a", "b"] } }会匹配["x", "a", "y", "b", "z"] - ⚠️ 别用
$in：它查的是「字段值是否在给定集合中」，不是「字段是否等于某个数组」，{ tags: { $in: [["a","b"]] } }看似可行，但实际依赖字段是单值还是数组，语义模糊且易错
嵌套数组或对象数组时，$eq 依然有效但要注意深相等
如果数组里是对象（比如 [{ name: "A", id: 1 }, { name: "B", id: 2 }]），$eq 仍能精确匹配，但 MongoDB 的对象比较是「字段名顺序无关 + 值严格相等」——也就是说 { id: 1, name: "A" } 和 { name: "A", id: 1 } 被视为相同。这点和 JS 不同，不必预排序键名。
- ✅ 可靠：
{ items: { $eq: [{ name: "A", id: 1 }, { name: "B", id: 2 }] } } - ❌ 失败场景：对象里有
Date、ObjectId或正则等特殊类型时，字面量写法容易出错。例如用字符串"60a1b2c3d4e5f67890123456"匹配ObjectId字段，必须先转成ObjectId("...")（在 shell 中）或对应驱动类型（在代码里） - ? 提示：用
mongosh测试时，可先db.coll.findOne()看真实存储结构，避免按自己想象构造查询
为什么不用 $elemMatch？它根本不是为这个设计的
$elemMatch 的唯一作用是「在一个数组的单个元素上同时满足多个条件」，比如「找 tags 数组里既有 level: "high" 又有 active: true 的那个对象」。它从不承诺数组整体结构一致，也不关心其他元素是否存在。
- ❌ 错误尝试：
{ tags: { $elemMatch: { $eq: ["a", "b"] } } }—— 语法错误，$elemMatch不接受$eq作为子句 - ❌ 更隐蔽的错：
{ tags: { $elemMatch: { $in: ["a", "b"] } } }—— 这是在查「至少一个元素是 "a" 或 "b"」，和数组结构完全无关 - ✅ 记住口诀：
$elemMatch= 「单个元素，多条件」；$eq= 「整个字段，一字不差」
索引与性能：数组字段建索引后，$eq 查询能走索引吗？
能，但有条件。MongoDB 对数组字段建索引时，会为每个元素单独建条目（multi-key index）。当用 $eq 匹配整个数组时，只要索引覆盖该字段（比如 { tags: 1 }），查询就能命中索引并高效执行 —— 前提是数组不超长（官方建议单文档数组元素不超过几百个）。
- ✅ 推荐建索引：
db.coll.createIndex({ tags: 1 }) - ⚠️ 注意：如果数组经常变化（频繁 push/pop），multi-key 索引更新开销略高，但比没索引全表扫强得多
- ? 验证是否走索引：
db.coll.find({ tags: { $eq: ["a", "b"] } }).explain("executionStats")，看executionStages.stage是否为IXSCAN，且nReturned≈totalDocsExamined
$eq 是唯一直接、无歧义、可索引的解法。别绕弯试 $all、$size 拼凑，也别在应用层拆开比 —— 那既慢又容易漏掉类型或空值差异。
