最常见原因是localField和foreignField类型不一致，如ObjectId与字符串ID无法匹配；其次为from集合名错误或不存在，$lookup不报错但返回空数组。
为什么 $lookup 有时查不到关联数据
最常见原因是 localField 和 foreignField 类型不一致——比如一边是 ObjectId，另一边是字符串 ID。MongoDB 不会自动转换，直接匹配失败，结果里 as 字段为空数组。
另一个高频坑：目标集合（from）名写错，或当前数据库里根本不存在该集合，$lookup 不报错，但返回空数组，容易误判为“没数据”而非“集合不存在”。
- 检查两边字段是否都是
ObjectId：用db.collection.findOne()看实际存储类型 - 确认
from是集合名（不含数据库前缀），且在当前数据库下存在 - 如果必须跨库关联，得用
pipeline形式配合$lookup的let+pipeline语法（MongoDB 3.6+），但原生不支持跨库，需应用层协调或使用物化视图
怎样写一个真正可用的左外连接
$lookup 默认就是左外连接：主集合每条文档都会保留，匹配不到则 as 字段为 []。关键在结构清晰、避免嵌套过深。
例如用户表 users 关联订单表 orders：
[
{
$lookup: {
from: "orders",
localField: "_id",
foreignField: "userId",
as: "userOrders"
}
}
]
注意：localField 是当前管道输入文档的字段（users._id），foreignField 是 orders 集合里的字段（orders.userId），两者值必须可精确匹配。
- 若只需订单数量，加
$addFields+$size：{ $size: "$userOrders" } - 若要限制每个用户只取最新 3 条订单，用
pipeline参数重写$lookup，内部加$sort和$limit - 不要在
$lookup后直接$unwind所有结果——这会把无订单用户过滤掉，破坏“左连接”语义
什么时候该用 pipeline 模式而不是基础 $lookup
基础 $lookup 只支持等值匹配；一旦需要条件过滤、字段投影、多级关联或字段类型转换，就必须升级到 pipeline 形式。
比如：只关联状态为 "paid" 的订单，并只返回 orderNo 和 total 字段：
[
{
$lookup: {
from: "orders",
let: { userId: "$_id" },
pipeline: [
{ $match: { $expr: { $eq: ["$userId", "$$userId"] } } },
{ $match: { status: "paid" } },
{ $project: { orderNo: 1, total: 1, _id: 0 } }
],
as: "paidOrders"
}
}
]
-
let用于把主文档字段传进子 pipeline，变量名前必须加$$ - 子 pipeline 中的
$match必须用$expr包裹表达式，普通字符串匹配会失效 - 每个子 pipeline 是独立执行环境，不能引用外部字段（除
$$变量外）
性能差？先看索引和数据分布
$lookup 性能瓶颈通常不在聚合本身，而在 foreignField 缺少索引。MongoDB 对 $lookup 的 foreignField 字段不做隐式索引，必须手动建。
对上面例子，确保 orders.userId 有索引：
db.orders.createIndex({ userId: 1 })
- 如果
foreignField是复合查询条件（如userId + status），建复合索引更有效 - 大数据量下，避免在
$lookup后立即$unwind再$group，容易触发内存限制（allowDiskUse: true可缓解但慢） - 单次
$lookup关联超过 10 万文档时，考虑分页或应用层 join，聚合阶段不是万能的
$lookup 不是 SQL 的 JOIN——它不支持 ON 多条件、不支持右连接、不自动去重。真正复杂的关系，还是得靠设计阶段就控制好引用粒度，或者接受部分逻辑移到应用代码里处理。 
