直接说重点：uniCloud的聚合流水线做多表联查，核心就是 db.collection().aggregate() 加上多个 $lookup 阶段。这里没有嵌套调用，是纯粹的“链式拼接”。官方JQL对多层 $lookup 支持有限，但聚合流水线（aggregate pipeline）本身就能串联起多个 lookup，还能带上 pipeline 做子查询，灵活度很高。
不少人一开始容易踩一个坑：把 lookup 当成函数来嵌套调用，比如写成 .lookup(...).lookup(...).end()，中间既没加 .match() 也没加 .project()，结果第二层 lookup 完全拿不到上一层输出的字段——这就卡住了。
这里有几个铁律，必须记牢：
from必须是一个真实的集合名字符串，不能传变量或表达式进去- 每一层
lookup的as字段名绝不能重复，后写的会把前面的覆盖掉 - 想基于上一层
lookup的结果再查第三张表，就必须用let+pipeline的组合拳，光靠localField和foreignField根本不够用 - 还有，
$和$$的区别要搞清楚：单美元（$_id）代表当前文档的字段，双美元（$$book_id）是let定义的变量，混用了准保出问题
三表联查实战：从订单到作者的正确打开方式
来，咱们看一个典型场景：订单（order）→ 商品（book）→ 作者（author）。假设 order.book_id 对应 book._id，而 book.author_id 对应 author._id。这时候不可能靠一次 lookup 就跨两跳完成，必须分步走，一步一个脚印。
第二步 lookup 的关键是：它必须嵌套在第一步的 pipeline 内部。通过 let 把上层的字段透传进去，结构就清晰了。看代码：
const res = await db.collection('order').aggregate()
.match({ _id: 'xxx' })
.lookup({
from: 'book',
let: { book_id: '$book_id' },
pipeline: $.pipeline()
.match(dbCmd.expr($.eq(['$_id', '$$book_id'])))
.lookup({
from: 'author',
let: { author_id: '$author_id' },
pipeline: $.pipeline()
.match(dbCmd.expr($.eq(['$_id', '$$author_id'])))
.done(),
as: 'author'
})
.done(),
as: 'book'
})
.end()
注意，这里的 $.pipeline() 是 uniCloud 独有的聚合子管道构造器，不是原生 MongoDB 语法；而 dbCmd.expr() 是包裹表达式的关键，能避免字符串拼接出错。把这两个用对了，这条流水线就能跑起来。
多副表、不同外键，怎么同时查？
如果你的主表有多个外键字段，比如 user_id（字符串）、category_id（字符串）、以及 tag_ids（数组），要关联不同的副表，那就不能指望 localField/foreignField 这种简单匹配了——尤其是当字段类型还不一样的时候，处理方式要分开：
- 字符串外键（比如
user_id），用标准的lookup设定好对应关系就行 - 数组外键（比如
tag_ids），就必须用let: { tag_ids: '$tag_ids' }，然后在pipeline里配合$.in(['$_id', '$$tag_ids'])这个表达式 - 每个
lookup的as名字必须唯一，比如分别是as: 'user'、as: 'category'、as: 'tags'
至于这些 lookup 的执行顺序，其实没有严格要求。不过建议先把单值关联（字符串外键）处理完，再处理数组关联，这样做能避免因为数据量过大而拖慢整个流水线的性能。
用了 aggregate 还查不到数据？问题多半出在这里
最常遇到的麻烦不是语法写错，而是两个要命的配置没到位：权限和索引。
- 权限没开：云数据库的集合有读权限控制，就算你在前端调用，聚合操作也得受服务空间的安全规则约束。如果
order和book这两个集合没有设置“所有人可读”或对应的角色权限，那查出来就是空。 - 索引没建：被
foreignField关联的字段，比如book._id和author._id，必须建有索引。否则聚合操作可能因效率问题超时，或者直接返回空数组，非常坑。 - API 用错了：千万别用
uniCloud.databaseForJQL()去调用aggregate()方法，JQL 实例不支持这个。必须使用uniCloud.database()实例。 - 云函数没部署：修改了云函数代码，但忘记点击“上传并部署”，那旧版本会一直运行，新代码自然没生效。
说了这么多，调试的时候最管用的方法就是去云函数日志里看 console.log(res) 的输出。别光盯着前端的 uni.showToast ——很多时候后端已经把数据返回来了，但前端没正确解构 res.data[0].book 这种嵌套结构。把日志一看，问题在哪就一目了然了。
