MongoDB作为文档型数据库，数据模型通常倾向于把强关联的数据嵌套在同一个文档里。但实际业务中，用户信息、订单记录、商品详情经常被拆分到不同集合，以降低冗余和提升写入灵活性。这时需要跨集合查询，客户端如果先查订单再逐一查用户，不仅代码繁琐，而且网络往返次数多，过滤和投影也无法在数据库端完成。$lookup阶段就是聚合管道中专门解决这类问题的工具，它可以在服务器端执行左外连接，将匹配到的外部集合文档合并到当前文档中，从而在一个聚合操作里完成关联查询。
下面以两个集合为例：users集合保存用户基础信息，orders集合保存订单，订单文档中的userId字段引用用户集合的_id。如果没有$lookup，开发者可能要先执行db.orders.find()拿到订单列表，再对每个订单查询一次用户，性能与可读性都很差。借助聚合管道，可以把关联逻辑全部下推到数据库。
一、$lookup基础语法与等值关联
$lookup最基础的形态只需要四个字段：from指定要关联的外部集合名称，localField表示当前管道文档中的字段，foreignField表示外部集合中用于匹配的字段，as表示关联结果要写入的新字段名。它执行的是左外连接，即使外部集合没有匹配项，源文档也会保留，只是关联字段会变成空数组。
例如查询每个订单对应的用户信息，可以这样写：
db.orders.aggregate([
{
$lookup: {
from: "users",
localField: "userId",
foreignField: "_id",
as: "userInfo"
}
}
])
执行后，每个订单文档都会多出一个userInfo数组，里面包含匹配到的用户文档。之所以是数组，是因为$lookup的设计允许多个外部文档命中同一个条件，即使一对一的场景也会返回数组。后续可以用$unwind展开，或使用$arrayElemAt取第一个元素。需要注意的是，关联字段的类型必须一致：如果orders.userId存储为字符串，而users._id是ObjectId，则无法匹配，需要在管道中先转换类型，或者写入时就保持统一。常见做法是存储为ObjectId，并在写入前用ObjectId()包装。
另一个容易忽略的问题是索引。等值关联时，如果外部集合的foreignField没有索引，MongoDB会对右集合进行全集合扫描，数据量一大就会变慢。通常users._id有默认唯一索引，但如果有别的字段作为关联键，务必提前创建索引。对于orders集合自身，如果后续还会按userId过滤，也建议建立单字段索引。
二、管道式$lookup处理复杂关联条件
MongoDB 3.6 开始支持管道式$lookup，语法中不再使用localField和foreignField，而是通过let定义变量，再在pipeline子管道里使用这些变量进行匹配。好处是可以在右集合上做过滤、投影、排序甚至再次关联，条件不再局限于简单等值。
下面这个例子关联用户，同时只取状态为活跃的用户，并且只返回用户名和邮箱：
db.orders.aggregate([
{
$lookup: {
from: "users",
let: { uid: "$userId" },
pipeline: [
{
$match: {
$expr: { $eq: ["$_id", "$$uid"] },
status: "active"
}
},
{
$project: { name: 1, email: 1, _id: 0 }
}
],
as: "userInfo"
}
}
])
这里let把当前文档的userId值保存到变量uid中，在子管道的$match阶段通过$expr使用$$uid引用它。这样既能做等值匹配，也能加入其他条件，比如状态过滤。相比基础形态，管道式$lookup更加灵活，能够减少返回的关联数据体积，降低网络和内存压力。
如果关联条件涉及多个字段，比如既要用户ID匹配，又要判断用户注册时间早于订单创建时间，可以在同一个$expr中用$and组合多个表达式。也可以把$limit、$sort放进子管道，只返回最新的一条匹配记录，避免大数组。需要注意的是，管道式$lookup在内部会为每个源文档执行一次子管道，如果源集合很大且没有合适的索引，开销会明显增加，因此尽量在进入$lookup前先对源文档做$match缩小范围。
三、$lookup结果展开与性能优化
$lookup默认把关联结果放进数组，后续处理时经常需要把数组拆成独立文档。例如订单关联用户后，希望把用户字段平铺到订单文档中，可以先用$unwind展开userInfo，再用$replaceRoot或$mergeObjects合并字段。
db.orders.aggregate([
{
$lookup: {
from: "users",
localField: "userId",
foreignField: "_id",
as: "userInfo"
}
},
{
$unwind: {
path: "$userInfo",
preserveNullAndEmptyArrays: true
}
},
{
$replaceRoot: {
newRoot: {
$mergeObjects: ["$$ROOT", "$userInfo"]
}
}
}
])
这段代码中preserveNullAndEmptyArrays设为true，是为了保留没有匹配到用户的订单，相当于左连接语义。如果设为false，没有用户的订单会被直接丢弃，行为更像内连接。合并后，userInfo中的字段会平铺到订单文档里，但要注意字段名冲突：如果两边都有同名字段，合并顺序决定了覆盖关系，后面的字段会覆盖前面的同名值。
性能方面，除了为关联字段创建索引，还要关注文档大小限制。聚合管道中每个文档经过$lookup后如果关联出超大数组，可能超过16MB的单文档限制，导致写入或返回失败。针对这种场景，优先在子管道里做$project裁剪字段，或者用$limit限制返回的匹配数量。对于只需要判断是否存在关联的情况，可以用$lookup加$match配合$size或$ne来判断数组是否为空，但更好的做法是把$lookup放在必要的过滤之后，减少参与关联的源文档数量。
四、$lookup与嵌入式文档的取舍
虽然$lookup解决了跨集合查询的问题，但并不意味着所有关联场景都应该拆分成多个集合再频繁使用$lookup。MongoDB的数据建模原则强调“合并访问的数据放在一起”，如果用户信息很少变化，并且订单查询时总是需要一起返回用户名和头像，把用户快照嵌入订单文档可能更合适。这样一次查询就能拿到全部数据，完全没有关联开销。
但嵌入也有代价：用户修改昵称或头像后，历史订单里的快照不会自动更新。如果业务要求实时显示最新用户信息，那么引用外部集合并使用$lookup才是合理选择。通常可以这样判断：数据更新频率低、读取频繁且几乎不变化，用嵌入；数据属于独立实体、需要多处引用或更新频繁，用引用加$lookup。另一种折中方案是保存基础字段的冗余副本，同时在查询时按需使用$lookup补充完整信息，这样能减少不必要的关联操作。
在实际聚合管道中，$lookup还可以与$graphLookup配合实现递归关联，比如组织架构、评论回复等树状或图状数据。不过这类查询复杂度更高，需要充分考虑索引和文档大小。掌握$lookup的基本用法与优化方向，能够帮助你在保留文档模型灵活性的同时，高效完成跨集合的数据整合。