$lookup在MongoDB 6.0中不能直接写SQL风格子查询，因其仅支持左外连接且必须通过pipeline+$$变量+ $expr 实现条件关联，直接写"$field"无效，须用"$expr: {$eq: ['$foreignField', '$$localField']}"。
为什么 $lookup 在 MongoDB 6.0 里不能直接写子查询
MongoDB 的 $lookup 本身不支持 SQL 风格的“子查询”语法（比如 SELECT * FROM a WHERE id IN (SELECT uid FROM b)），它只做左外连接，且 pipeline 参数虽支持聚合阶段，但必须明确指定 from 集合、localField 和 foreignField 的映射关系。常见误解是以为能在 pipeline 里随意嵌套 $match 引用上层文档字段——其实可以，但必须用 $expr + 变量绑定，否则查不到数据。
容易踩的坑：pipeline 中直接写 { $match: { "user_id": "$order_user_id" } } 是无效的，因为字段名没被识别为变量；必须写成 { $expr: { $eq: ["$user_id", "$$order_user_id"] } }，其中 $$order_user_id 是从外层传入的变量。
怎么用 pipeline 实现带条件的嵌套关联
在 MongoDB 6.0 中，$lookup 的 pipeline 字段允许你对关联集合做预过滤、投影甚至多级聚合，这是实现“类子查询”逻辑的核心方式。关键点在于变量传递和表达式写法。
- 外层文档字段需用
$$前缀引用（如$$orderId），不能漏掉双美元符 -
pipeline内部不能直接访问外层字段，所有引用都必须通过$expr+$$变量完成 - 如果要关联多个条件（如 status=1 且 type="paid"），全部塞进
$expr的$and里，不要拆成多个$match - 记得在
pipeline开头加{ $match: { $expr: ... } }，否则过滤不生效
示例：查订单，同时关联该订单下状态为 "shipped" 的物流记录：
[
{
$lookup: {
from: "shipments",
localField: "order_id",
foreignField: "order_id",
as: "shipment",
pipeline: [
{ $match: { $expr: { $eq: ["$order_id", "$$order_id"] } } },
{ $match: { status: "shipped" } }
]
}
}
]嵌套两层关联（比如订单 → 商品 → 库存）怎么写
MongoDB 不支持链式 $lookup 直接跨三层，但可以在第一层 $lookup 的 pipeline 中再嵌一个 $lookup。注意：内层 $lookup 的 from 是另一个集合，而 localField 必须是当前 pipeline 上下文中的字段（比如商品文档里的 sku），不是原始订单字段。
常见错误是试图在第二层 $lookup 中还引用 $$order_id —— 它在内层 pipeline 里已不可见。
- 第一层
$lookup关联商品，as: "items" - 第二层嵌在 items 的
pipeline里，用localField: "sku"关联库存集合 - 若需按订单维度过滤库存（如只查该订单对应仓库的库存），得在第二层
$match中用$expr绑定$$this.warehouse_id和外层传入的变量（需提前用$addFields把订单 warehouse_id 注入到 items 文档中）
所以真正实用的三层关联，往往需要先 $unwind items，再 $lookup 库存，最后 $group 回去，而不是全压在单个 $lookup.pipeline 里。
性能和兼容性要注意什么
MongoDB 6.0 对 $lookup pipeline 的优化有限，尤其当关联集合大、pipeline 复杂时，很容易触发内存限制或全表扫描。
- 确保
foreignField和pipeline中用于匹配的字段都有索引（如shipments.order_id、inventory.sku） - 避免在
pipeline里用$sort或$skip，它们无法利用索引，且会强制加载全部中间结果 - 如果只是想“判断是否存在”，用
$limit: 1+$project: { _id: 1 }替代返回全部字段，减少网络和内存开销 - 6.0 不支持
$lookup的let参数以外的变量注入方式，别尝试用$function或$reduce模拟子查询逻辑，性能极差且不可靠
最易被忽略的是：pipeline 中的 $match 如果没包在 $expr 里且字段名碰巧和外层同名，MongoDB 会静默忽略这个条件，查出来一堆无关数据，debug 时很难定位。
