查字段为null或缺失需用$or：{ $or: [ { field: { $eq: null } }, { field: { $exists: false } } ] }，因{field: null}语义模糊且索引行为异常。
查字段为 null 或根本不存在的文档，用 $or 配合 $exists 和 $eq
MongoDB 里 null 和字段缺失（即该键根本没出现在文档中）是两种不同情况，{$field: null} 默认会同时匹配二者，但有时你得明确区分。真要查“值为 null”或“字段压根不存在”，必须拆开写：$or 是唯一稳妥方式。
常见错误是只写 {field: null}，它确实能返回两类文档，但语义模糊——你无法判断结果里哪些是存了 null，哪些是字段缺失；更麻烦的是，如果字段类型本该是字符串或数字，存了 null 往往是数据异常，而缺失可能是正常逻辑（比如可选字段），混在一起查就失去排查意义。
-
{$or: [{field: {$eq: null}}, {field: {$exists: false}}]}—— 明确抓出“值为null”和“字段不存在”两类 - 如果只想查“字段存在但值为
null”，用{field: {$eq: null}, field: {$exists: true}}（注意两个条件并列，不是嵌套） - 如果只想查“字段缺失”，直接用
{field: {$exists: false}}，别信{field: null}，后者在有索引时可能走错执行计划
$exists: false 的行为和索引影响
$exists: false 看似简单，但它不走常规索引：MongoDB 不会对“不存在”的字段建索引项，所以这个查询必然是全表扫描（collection scan）。哪怕你在 field 上建了索引，{field: {$exists: false}} 也用不上。
实际场景中，如果集合很大且这类查询频繁，得提前规划：要么加一个标记字段（如 field_missing: true），给它建索引；要么在写入时统一补默认值（如空字符串、0），把“缺失”转成“有值但为空”，再用等值查询 + 索引加速。
- 验证是否走索引：用
.explain("executionStats")，看executionStages.stage是不是COLLSCAN -
$exists: true可以走索引，但前提是字段在索引中且大多数文档都含该字段，否则优化器可能仍选全表扫描 - 复合索引中，
$exists: false不能作为前导匹配条件，放在后面也没用
聚合管道里怎么处理 null 和缺失字段
聚合阶段（如 $match、$project）对 null 和缺失字段的响应更严格。比如 $match 中写 {field: null}，行为和 find 一样；但到了 $project 里用 $ifNull，它的第一个参数只认“字段存在但值为 null 或 undefined”，对缺失字段无效——$ifNull 会直接跳过这个字段，不触发 fallback。
- 安全兜底用
$cond+$exists：{$cond: [{ $not: ["$field"] }, "default", "$field"]}不够准，应改用{$cond: [{ $or: [ { $eq: ["$field", null] }, { $not: { $exists: "$field" } } ] }, "default", "$field"]} -
$addFields阶段想补缺失字段，用{field: {$ifNull: ["$field", "default"]}}只能补null，补不了缺失；得先$set一个临时字段判断存在性，再分路处理 - 排序时
null和缺失字段都被当作最小值，sort({field: 1})会把它们排最前，但顺序不确定
Shell 和驱动里的写法差异（以 Node.js 为例）
MongoDB Shell 里写 {field: null} 是字面意思，但 Node.js 驱动（如 mongodb@6+）传参时，null 值会被自动忽略——如果你构造查询对象时写了 { field: someVar } 而 someVar === null，驱动默认删掉这个键，结果变成 {}，查出全部文档。
- 显式传
null必须用$eq：{ field: { $eq: null } } -
$exists: false没这个问题，直接写就行 - TypeScript 用户注意：
field?: string类型定义下，null不属于string，编译期就报错，得用联合类型string | null | undefined，且运行时还得手动过滤undefined
null 和字段缺失在语义、索引行为、聚合处理上都不等价，硬凑成一个查询条件看似省事，后续调试和性能问题会集中爆发。真正要稳，就得在查询意图层面先分清——是查异常数据，还是查设计上的可选字段。 
