MongoDB 数组范围查询匹配了没有区间内元素的文档

查询条件写成 { scores: { $gt: 10, $lt: 20 } }，结果却包含 scores: [4, 30]。数组里没有一个数落在这个开区间，文档仍然匹配，因为两个比较条件可以分别由不同元素满足：30 > 10，4 < 20。

如果业务要求“至少一个元素同时大于 10、小于 20”，需要把两个条件放进查询操作符 $elemMatch。这里讨论普通数值数组和 find() 的文档筛选；嵌套数组、字符串数字以及返回结果中的数组裁剪，需要另行判断。

把“同一个元素”写进条件

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

{"_id": "a", "scores": [4, 30]}
{"_id": "b", "scores": [12, 30]}
{"_id": "c", "scores": [2, 8]}

下面的筛选允许多个数组元素共同满足条件，按这份样例会选中 a 和 b：

db.measurements.find(
  { scores: { $gt: 10, $lt: 20 } },
  { _id: 1, scores: 1 }
)

改成同一元素匹配：

db.measurements.find(
  { scores: { $elemMatch: { $gt: 10, $lt: 20 } } },
  { _id: 1, scores: 1 }
)

按相同样例，新条件只选中 b，因为 12 同时通过两个比较。a 的 4 与 30 不能再拼成一次成功匹配。条件也没有按数组顺序逐项“用掉”的规则；交换元素顺序不会把这个判断变成逐个消费条件。

不要只把两个比较移到外层 $and，便以为已经绑定了同一个数组元素。需要表达的约束是元素身份相同，$elemMatch 正是这层约束。

查询选中文档，不会自动删掉数组中的其他值

新查询返回 b 时，scores 仍会是 [12, 30]。看见返回数组里还有 30，不代表条件失效：文档中存在符合条件的 12，已满足筛选要求。

上例把 $elemMatch 放在 find() 的第一个参数。第二个参数中的 scores: 1 只是保留这个字段，因此会显示完整数组。若接口还要求只返回区间内的元素，应另行设计返回字段的处理，不要把文档筛选和数组内容裁剪混在同一次判断里。

同名的投影 $elemMatch 有不同用途，不能简单移到第二个参数来替代筛选条件。先验证“哪些文档应被选中”，再处理“文档应显示哪些元素”。

修正前确认字段确实是数值数组

$elemMatch 只匹配数组元素。如果历史记录把 scores 保存成标量 12，普通范围查询可以匹配这个标量，而上面的 $elemMatch 不会。上线后结果变少，可能同时包含了排除跨元素匹配和排除标量记录这两种变化。

在小型脱敏副本中检查字段形状，并纳入这些边界：

• [4, 30]：旧条件匹配，新条件不匹配。
• [12, 30]：两种条件都匹配，新结果仍保留整个数组。
• [10, 20]：新条件不匹配，因为这里使用严格的 $gt 和 $lt。
• 空数组、缺少字段，以及标量 12：不应被新数组条件选中。

如果区间包含端点，应根据业务改用 $gte 或 $lte，不能为了让某条记录出现而临时放宽范围。字符串形式的数字也不应当作数值数组直接套用这组预期；先核对保存的数据类型与应用模型。

保留业务过滤，再替换这一段条件

实际查询中已有的租户、状态、时间等条件应继续保留，只替换目标数组的范围表达式。在测试副本中比较新旧查询选中的文档身份，并逐条解释差异，不要只比较总条数。

这个修复不需要修改已有文档，也不需要删除或重建索引来改变匹配语义。保留旧查询代码可回退，但只有业务本来就允许不同元素分别满足条件时，旧写法才符合要求。若筛选结果后续会用于更新、计费或通知，应先验证选中范围，再恢复这些有副作用的流程。