$lookup是MongoDB实现左外连接的唯一标准方式，必须指定localField和foreignField，二者大小写敏感且需存在于对应集合中；跨库关联需用{db: "", coll: ""}格式；性能优化需避免前置$unwind、确保字段索引、限制嵌套层级并提前投影裁剪。
$lookup 是 MongoDB 实现左外连接的唯一标准方式，不是“可以”，而是“必须用它”——其他操作符（如 $unionWith、$facet）不提供字段级关联能力。
为什么 $lookup 报错 “requires at least one localField and one foreignField”
这个错误不是语法写错了，而是 $lookup 阶段里漏掉了 localField 或 foreignField 中的任意一个，或者字段名拼写与实际文档结构不一致。
- 检查是否误写成
localfield（小写）或LocalField（驼峰）——MongoDB 严格区分大小写，正确字段名是localField和foreignField - 确认
localField确实存在于输入文档中（比如聚合起始集合的每个文档都有userId字段），空值或缺失字段不会报错，但会导致无匹配结果 -
foreignField必须在from指定的集合中存在且类型兼容；例如用字符串匹配 ObjectId 会静默失败（不报错，但无结果） - 如果使用 Atlas Data Federation，
from必须是对象形式{db: "otherdb", coll: "orders"}，不能只写字符串，否则也会触发该错误
跨数据库关联时 from 字段怎么写才有效
在 Atlas 或支持 federation 的部署中，跨库关联不是加个前缀那么简单，from 必须显式声明数据库名，且后续嵌套 $lookup 会继承该上下文。
- 正确写法：
from: {db: "analytics", coll: "events"}—— 这是唯一被 federation 认可的跨库语法 - 错误写法：
from: "analytics.events"或from: "events"（没指定 db）都会回退到当前数据库，导致查不到数据 - 如果第一层
$lookup已指定{db: "logs", coll: "errors"}，其输出文档进入下一层$lookup时，若新$lookup未再声明db，则自动沿用"logs"，而非原始命令所在库 - 分片集合仅在 MongoDB 5.1+ Atlas 集群中支持跨库
$lookup；自建 6.x 集群不支持跨库，即使语法合法也会报错
性能崩了？先看这三个地方有没有优化
$lookup 性能差，90% 不是因为数据量大，而是管道设计没避开常见陷阱。
- 不要在
$lookup前放$unwind——这会让左表每条记录都触发一次右表全量扫描，复杂度从 O(N) 变成 O(N×M) -
localField和foreignField必须有索引；尤其当右表很大时，缺索引会让单次 lookup 耗时从毫秒级升到秒级 - 避免多层嵌套
$lookup：三层以上关联极易触发内存溢出（errmsg: "Sort exceeded memory limit"），应优先考虑客户端拼接或预聚合 - 用
$project提前裁剪右表字段，比如{ $project: { name: 1, status: 1, _id: 0 } }，减少传输和内存占用
如何实现“内连接”效果而不是默认左连接
$lookup 本身只能做左外连接，但你可以用后续阶段过滤掉无匹配项，等效得到内连接语义。
- 加
$match判断as字段非空：{ $match: { "joinedData.0": { $exists: true } } } - 更安全的写法是配合
$size：{ $match: { "joinedData.0": { $ne: null } } }（注意：null 不等于空数组） - 如果需要展开后去重或扁平化，紧接着用
$unwind，但要加preserveNullAndEmptyArrays: false参数，否则空数组也会产出文档 - 别试图用
$lookup+$filter模拟内连接——逻辑绕、性能差，不如直接$match过滤
真正容易被忽略的是：$lookup 的匹配是逐文档进行的，没有“批量 join”机制。哪怕你只想要 10 条结果，MongoDB 仍会对输入流中每一条文档单独发起一次右表查询。这意味着，如果你没在最前面用 $match 尽可能缩小左表数据集，性能损耗会指数级放大。
