$lookup匹配失败时返回空数组[]而非null，导致脏数据被误判为“无匹配”；根本原因是localField与foreignField类型不一致、字段缺失或值为null，需用$exists false精准识别“仅A有”，并结合$type校验和pipeline预过滤确保匹配有效性。
为什么 $lookup 直接比对总是漏掉脏数据
因为 $lookup 默认返回数组，匹配失败时填的是空数组 []，而不是 null 或缺失字段。如果你只写 { $match: { "b.0": { $exists: true } } }，看似在找“有匹配的”，但一旦 localField 是 null、undefined、字符串 ID 和 ObjectId 混用，或者字段类型不一致（比如 A 集合存的是字符串 "123"，B 集合存的是数字 123），$lookup 就静默跳过——结果仍是 []，被你误判为“没数据”，实则根本没比对上。
常见错误现象包括：
- 查出“两集合完全一致”，但人工抽样发现字段值明显不同
-
count()返回 0，但实际 B 集合里明明有对应文档 - 校验脚本在测试环境通过，上线后大量误报“仅 A 有”
怎么写 $lookup 才能真正识别三类不一致
目标不是“找出匹配项”，而是精准捕获：仅 A 有、仅 B 有、A 和 B 都有但值不同。单靠一次 $lookup 不够，必须组合使用：
- 查
仅 A 有：用$lookup关联后，检查"b.0"是否不存在（比"b"是否为空数组更准，规避了空数组干扰） - 查
仅 B 有：反向再做一次$lookup（B → A），同样用"a.0"判断 - 查
值不同：在正向$lookup后加$set提取关键字段，再用$expr+$ne显式比对，例如{ $ne: ["$key", "$b.0.key"] } - 务必在
$lookup的pipeline参数里过滤右集合，别等关联完再$match——否则无效文档早已丢弃，条件失效
示例片段（校验 orders.user_id 与 users._id 是否一致）：
{ $lookup: {
from: "users",
localField: "user_id",
foreignField: "_id",
as: "u",
pipeline: [ { $match: { status: "active" } } ]
} },
{ $set: { u_key: { $ifNull: ["$u.0._id", null] } } },
{ $match: { $or: [
{ "u.0": { $exists: false } }, // 仅 orders 有
{ $ne: ["$user_id", "$u_key"] } // 类型或值不等
] } }
字段类型和空值不处理，校验就等于没做
MongoDB 不自动转换类型，"123" ≠ 123，null ≠ []，这些都会让 $lookup 匹配失败。必须提前验证并统一：
- 用
db.collectionA.findOne().keyField和db.collectionB.findOne().keyField手动确认值与类型是否一致 - 聚合中加
$type阶段过滤异常类型，例如{ $match: { key: { $type: "objectId" } } } -
localField是数组？$lookup会自动展开匹配，但如果含null或混合类型，整条匹配静默跳过——得先$filter清洗 - foreignField 没建索引？全表扫描导致超时或结果截断，看起来像“没找到”，实际是性能问题
什么时候该放弃 $lookup，改用两次 find
当校验逻辑复杂到需要多次反向关联、嵌套比对、或涉及时间范围动态计算（如 “B 集合中最新一条匹配记录”）时，硬塞进聚合管道反而难读难调、性能差。此时更稳妥的做法是：
- 用应用层分两步
find：先拉 A 集合关键字段，再用$in批量查 B 集合对应记录 - 在内存中比对，显式处理类型转换、空值、去重、排序
- 尤其适合一次性校验、离线任务、或需详细脏数据报告的场景
聚合管道适合高吞吐、流式、嵌入式校验；而复杂逻辑 + 可控调试 + 明确错误上下文，往往属于应用代码的职责边界。
最容易被忽略的一点：校验结果里的“一致”，永远依赖于你是否真的控制了字段类型、空值语义和索引有效性——不是 $lookup 跑通了，数据就干净了。
