$lookup 是唯一支持跨集合关联的聚合阶段，必须使用且需正确配置 localField 和 foreignField；跨库关联须用 {db: "name", coll: "name"} 格式；性能优化关键在于避免前置 $unwind、确保字段索引及类型匹配。
$lookup 是唯一能做跨集合关联的聚合阶段，不是“可选”，而是“必须用它”——其他操作符不提供字段级关联能力。
为什么 $lookup 报错 “requires at least one localField and one foreignField”
这个错误不是语法写错了，而是漏了 localField 或 foreignField，或者字段名拼写与实际文档结构不一致。
- 检查是否误写成
localfield（全小写）或LocalField（驼峰）——MongoDB 严格区分大小写，正确字段名是localField和foreignField - 确认
localField确实存在于输入文档中（比如聚合起始集合每个文档都有userId字段），空值或缺失字段不会报错，但匹配结果为空 -
foreignField必须在from指定的集合中存在且类型兼容；例如用字符串匹配ObjectId会静默失败（不报错，但无结果） - 如果使用 Atlas Data Federation，
from必须是对象形式{db: "otherdb", coll: "orders"}，不能只写字符串，否则触发该错误
跨数据库关联时 from 字段怎么写才有效
跨库不是加个前缀那么简单，from 必须显式声明数据库名，且后续嵌套 $lookup 会继承该上下文。
- 正确写法：
from: {db: "analytics", coll: "events"}—— 这是唯一被 federation 认可的跨库语法 - 错误写法：
from: "analytics.events"或from: "events"都会回退到当前数据库，导致查不到数据 - 如果第一层
$lookup已指定{db: "logs", coll: "errors"}，其输出文档进入下一层$lookup时，若新$lookup未再声明db，则自动沿用"logs"，而非原始命令所在库 - 分片集合仅在 MongoDB 5.1+ Atlas 集群中支持跨库
$lookup；自建 6.x 集群不支持跨库，即使语法合法也会报错
性能崩了？先看这三个地方有没有优化
$lookup 性能差，90% 不是因为数据量大，而是管道设计没避开常见陷阱。
- 避免前置
$unwind：在$lookup前展开数组会导致笛卡尔积式膨胀，应尽量后置或改用带pipeline的$lookup - 确保
localField和foreignField都有索引：尤其当foreignField是非主键字段时，缺失索引会让查询变成全表扫描 - 限制嵌套层级并提前投影裁剪：每层
$lookup都会增加内存和网络开销；用$project提前去掉不需要的字段，避免把整个文档拖进来
最容易被忽略的是字段类型兼容性——localField 是 ObjectId，foreignField 却存成字符串，这种关联永远无声失败，连日志都不会报错。
