MongoDB 6.0 的 $lookup 简写模式（非 pipeline）仅支持单字段、同类型、有索引的等值关联，本质是语法糖；类型不一致或缺索引会导致静默失败或性能暴跌，复杂需求必须退回 pipeline 模式。
MongoDB 6.0 的 $lookup 不再需要显式写 pipeline 就能做字段级关联，但很多人误以为“简化”等于“随便写”，结果查不出数据或性能暴跌。
为什么不用 pipeline 也能关联了？
MongoDB 6.0 引入了 localField/foreignField 的简写模式（即“非 pipeline 模式”），前提是目标集合有对应字段的索引，且关联字段类型严格一致。它本质是语法糖，底层仍走 hash join 或 sort-merge join，但省去了写 [$match, $project] 的样板代码。
- 必须满足：
localField和foreignField都是单字段、非数组、类型完全相同（比如都是ObjectId或都是字符串） - 不支持：字段嵌套（如
"user.profile.id"）、表达式（如{"$toString": "$_id"}）、多字段联合关联 - 如果违反上述任一条件，MongoDB 会静默退回到旧版行为——报错或返回空数组，不会提示“请改用 pipeline”
常见错误：关联结果为空，但 collection 确实有数据
最典型的情况是字段类型不匹配：比如本地集合用字符串存用户 ID（"123"），而远程集合用 ObjectId("123")。MongoDB 不做隐式转换，直接跳过匹配。
- 检查方式：在 shell 中分别执行
db.orders.findOne().userId和db.users.findOne()._id，看类型是否一致 - 修复路径：统一用
ObjectId，或用 pipeline 模式手动转类型（{"$toString": "$_id"}） - 另一个坑：
foreignField字段没建索引——即使语法合法，查询也会变全表扫描，延迟飙升
什么时候必须退回 pipeline 模式？
只要需求超出单字段等值匹配，就必须显式写 pipeline。这不是退化，而是唯一正确解法。
- 需要过滤关联数据：比如只查“状态为 active 的用户”，就得在 pipeline 里加
{"$match": {"status": "active"}} - 需要字段重命名或计算：比如把
users.name改成authorName，得用{"$addFields": {"authorName": "$name"}} - 关联字段在嵌套对象里：如
localField: "meta.createdBy"→ 必须用 pipeline +$expr表达式 - MongoDB 6.0 的 pipeline 模式还支持
$lookup内部使用变量（let）和$expr，这是简写模式完全不支持的
性能差异：简写快，但别迷信
简写模式在理想条件下确实更快，因为优化器能直接下推 join 条件；但一旦字段没索引，或者数据倾斜（比如一个 categoryId 关联 50 万条商品），它反而比带 $limit 的 pipeline 更慢——因为没法提前截断。
- 线上建议：对高频关联字段，强制加复合索引，例如
db.users.createIndex({"tenantId": 1, "_id": 1}) - 测试技巧：用
explain("executionStats")对比两种写法的nReturned和totalDocsExamined - 特别注意：简写模式不支持
maxTimeMS控制单次 lookup 耗时，超时风险更高
真正容易被忽略的不是语法怎么写，而是类型一致性检查和索引覆盖——这两个点出问题，连最基本的“有数据却查不到”都解决不了。
