$lookup 的 pipeline 中不能直接用字符串匹配多个字段，因为必须使用 $expr 表达式配合 $and 组合等值条件，本地字段写为 "$field"、被查字段写为 "$$this.field"，且字段类型需严格一致。
为什么 $lookup 的 pipeline 里不能直接用字符串匹配多个字段
因为 $lookup 的 pipeline 选项要求关联条件必须写成 $expr 表达式，而早期写法如 {"field1": "$other.field1", "field2": "$other.field2"} 在 pipeline 模式下会被当作字面量对象处理，根本不会触发变量引用——MongoDB 6.0 严格区分了「非 pipeline 关联」和「pipeline 关联」的语法语义。
常见错误现象：no match found 或返回空数组，即使源数据明显存在对应记录；日志里看不到报错，但结果静默失败。
- 必须把所有关联条件包进
$expr，再用$and组合多个等值判断 - 左右字段名要带完整路径：被查集合字段用
"$$field"（注意双美元），本地字段用"$field" - 字段类型必须一致，比如
ObjectId和字符串 ID 混用会导致匹配失败，且无提示
怎么写一个带 status + category 双条件的 $lookup pipeline
假设你有 orders 集合，想关联 products 集合，但只取 status: "active" 且 category: "electronics" 的商品。关键不是“能不能”，而是“怎么让 pipeline 知道你要比哪几个字段”。
db.orders.aggregate([
{
$lookup: {
from: "products",
localField: "product_id",
foreignField: "_id",
as: "matched_product",
pipeline: [
{
$match: {
$expr: {
$and: [
{ $eq: ["$status", "active"] },
{ $eq: ["$category", "electronics"] }
]
}
}
}
]
}
}
])
注意这里没用 localField/foreignField 做主键关联——那是在非 pipeline 模式下才生效的。一旦用了 pipeline，MongoDB 就完全忽略这两个字段，只认 pipeline 里的 $match 表达式。
- 如果还要按订单里的
region字段去匹配 product 的available_in数组，就加一条{ $in: ["$region", "$available_in"] } - 不要在 pipeline 里写
$lookup嵌套，6.0 不支持 pipeline 内再 $lookup（会报unrecognized field 'lookup'） - 若
product_id是字符串而非ObjectId，记得在$match里先用$toObjectId转换，否则$eq比较一定失败
当需要关联字段来自不同层级嵌套对象时怎么处理
比如 orders 里有个 shipping.address.city，你想匹配 warehouses 集合的 location.city，同时还要限制 warehouses.status === "operational"。这时候变量路径容易写错。
正确写法是：本地字段用 "$shipping.address.city"，被查字段用 "$$this.location.city"（$$this 指当前 pipeline 正在遍历的 warehouses 文档）。
pipeline: [
{
$match: {
$expr: {
$and: [
{ $eq: ["$shipping.address.city", "$$this.location.city"] },
{ $eq: ["$$this.status", "operational"] }
]
}
}
}
]
-
$$this是 pipeline 中对被查集合每条文档的默认引用，不能省略或改成其他变量名 - 如果本地字段是数组（如
order.tags），要用$in而不是$eq，且注意顺序：被查字段在前，本地字段在后 - 使用
$lookuppipeline 时，性能比传统模式低，尤其当被查集合没建好复合索引（例如{ location.city: 1, status: 1 }）时，很容易全表扫描
聚合阶段后怎么安全取关联结果的第一条而不是整个数组
很多人以为加个 $arrayElemAt: ["$matched_product", 0] 就完事，但这样会在没有匹配时返回 null，后续字段访问（比如 $matched_product.name）会出错。更稳妥的是先 $cond 判断数组长度。
{
$addFields: {
product: {
$cond: {
if: { $gt: [{ $size: "$matched_product" }, 0] },
then: { $arrayElemAt: ["$matched_product", 0] },
else: null
}
}
}
}
之后就能安全地用 "$product.name" 或 "$product.price" 做后续计算。别跳过这步——线上环境里，关联失败是常态，不是例外。
真正容易被忽略的点：pipeline 内 $match 的执行时机是在 from 集合上做筛选，不经过 orders 的任何索引；所以关联条件越早收敛（比如加 $status 过滤），整体耗时越可控。写完务必用 explain("executionStats") 看 nReturned 和 totalDocsExamined。
