$lookup跨集合校验必须配合类型校验、空值处理和索引优化，否则易误判；正确做法是用pipeline预过滤、显式比对字段类型与值，并分三类状态（仅A有、仅B有、值不同）精准识别脏数据。
直接用 $lookup 做跨集合数据校验可行，但必须配合类型校验、空数组判断和字段对齐，否则结果不可信——比如 count 为 0 很可能不是“没数据”，而是字段类型不匹配或 localField 为空。
为什么 $lookup 校验总显示“无差异”却实际有脏数据
常见错误是把 $lookup 当成 SQL JOIN 直接套用，忽略它默认返回数组、且匹配失败时填空数组 [] 的行为。当你只查 matched: { $ne: [] }，却没检查 localField 是否为 null、undefined 或字符串 ID 与 ObjectId 混用，校验就完全失效。
- 用
db.collectionA.findOne().keyField和db.collectionB.findOne().keyField分别验证值和类型，推荐加typeof或$type聚合阶段比对 -
localField是数组？$lookup会自动展开匹配，但若其中含空值或类型错乱，整条匹配就静默跳过 - 没建索引的
foreignField会导致全表扫描，超时或返回截断结果，看起来像“没找到”
安全写法：用 pipeline + $match 显式控制右集合过滤
不要依赖后续 $match 过滤右集合文档——$lookup 已完成关联后才进下一阶段，无效文档早被丢弃。必须把条件塞进 pipeline 参数里，让 MongoDB 在拉取前就筛一遍。
- 错误写法：
{ $lookup: { from: "collectionB", localField: "id", foreignField: "_id", as: "b" } }, { $match: { "b.status": "active" } }——b是数组，"b.status"匹配的是整个数组字段，不是每个元素 - 正确写法：
{ $lookup: { from: "collectionB", localField: "id", foreignField: "_id", as: "b", pipeline: [ { $match: { status: "active" } } ] } } - 如果右集合要按时间范围过滤，
pipeline里必须用$expr引用左文档字段，例如{ $match: { $and: [ { updatedAt: { $gte: "$$NOW" } } ] } }
校验逻辑怎么写才不漏判、不误判
目标不是“找出所有匹配项”，而是“确认两集合在关键字段上是否严格一致”。这意味着你要分别捕获三类状态：仅 A 有、仅 B 有、A 和 B 都有但值不同。单靠一个 $lookup 不够，得组合 $setDifference 或两次反向 $lookup。
- 查“仅 A 有”的文档：
{ $lookup: { from: "collectionB", localField: "key", foreignField: "key", as: "b_match" } }, { $match: { "b_match.0": { $exists: false } } }（用"b_match.0"比matched: []更准，避免空数组干扰） - 查“仅 B 有”的文档：反过来对
collectionB做$lookup关联collectionA，再筛空 - 查“键相同但其他字段不一致”：先
$lookup拉出b_match，再$unwind后用$expr比对具体字段，如{ $expr: { $ne: ["$name", "$b_match.name"] } }
性能与一致性边界必须手动兜底
$lookup 不走索引优化、无缓存、不保证事务一致性——它查到的右集合快照，可能比左集合文档旧几毫秒。高并发更新场景下，“校验通过”不等于“此刻一致”。
- 实时性要求高？加时间窗口过滤，例如
{ updatedAt: { $gt: { $subtract: ["$$NOW", 300000] } } }，舍弃 5 分钟前的数据参与校验 - 右集合数据量大？在
pipeline里用$project只保留校验所需字段，减少网络和内存开销 - 跨分片集群？确认两个集合都未分片，或分片键完全一致并路由到同一分片，否则
$lookup返回空也不报错
最容易被忽略的是：校验脚本运行期间，源集合可能正在被写入。没有读锁或快照隔离，结果天然带最终一致性窗口——这不是 bug，是模型决定的，得在业务层接受或补定时重试逻辑。
