应使用$exists:false查询字段不存在的文档，因其语义清晰、行为确定、全版本兼容；$type仅判断已存在字段的值类型，对缺失字段无感知，不可替代$exists。
直接用 $exists:false，别碰 $type
查“缺失字段”的文档，$type 根本不适用——它只判断**已存在字段的值类型**，对缺失字段完全无感知。$type 返回空结果，不是因为没匹配上，而是因为字段压根不在文档里，连参与判断的资格都没有。真正该用的是 $exists:false，语义清晰、行为确定、全版本兼容。
$type 在 $match 阶段能查 null 吗？能，但要写对
$type:10 或 $type:"null"（4.0+）可以精准命中值为 BSON null 的字段，但它不会把缺失字段也拉进来。常见错误是误以为 {field: {$type: "null"}} 和 {field: null} 等价——后者实际等效于 {$or: [{field: {$type: 10}}, {field: {$exists: false}}]}，语义完全不同。
-
{field: {$type: 10}}→ 只返回{field: null} -
{field: null}→ 返回{field: null}和{}（无 field） -
{field: {$exists: false}}→ 只返回{}
聚合管道里 $match 遇到缺失字段会怎样？
$match 阶段对缺失字段的处理很干脆：直接过滤掉。也就是说，如果文档里没有 price 字段，而你写了 {$match: {"price": {$gt: 100}}}，这条文档就不会进入后续阶段——哪怕它其实该被保留。这不是 bug，是设计行为。
- 缺失字段 →
$match表达式求值为false→ 文档被丢弃 - 想保留缺失字段的文档？必须显式用
$exists或$or拆开逻辑 - 例如查 “price > 100 或 price 缺失”：
{$match: {$or: [{"price": {$gt: 100}}, {"price": {$exists: false}}]}}
为什么有人非要用 $type 查缺失字段？踩坑点在哪
本质是混淆了三个独立概念：字段存在性（$exists）、字段值是否为 null（$type:10 或 $eq:null）、字段值类型（$type:2 等）。最容易被忽略的是：BSON null 是一个合法值类型，和“字段不存在”在存储层就是两回事，驱动、索引、聚合阶段都按此区分处理。硬用 $type 去覆盖缺失场景，只会让查询变慢、结果不可控、升级后突然失效。
