uniCloud 云数据库不支持传统 SQL 的 JOIN，但可通过 JQL 的 $lookup 实现等效联表查询，本质是两次查询加内存拼接；需注意字段类型一致、权限配置、云函数部署及 H5 调试等关键点。
uniCloud 云数据库支持联表查询吗？
不支持传统 SQL 的 JOIN，但 uniCloud 提供了 JQL（JSON Query Language）语法，通过 $lookup 实现等效的“联表”效果。它不是在数据库层做物理关联，而是在查询时按字段匹配、拉取另一集合的文档，本质是两次查询 + 内存拼接。
用 JQL 写联表查询的正确姿势
JQL 是 uniCloud 云数据库唯一的声明式查询语言，必须写在云函数里（前端不能直接调用），且需配合 get() 才会执行。
-
$lookup必须写在where()之后、get()之前，结构为：{ $lookup: { from: 'user', localField: 'user_id', foreignField: '_id', as: 'author' } } -
localField和foreignField类型必须一致：比如user_id是字符串，user._id也得是字符串（不能是 ObjectId）；否则查不到数据 -
as指定的结果字段是数组，即使只匹配一条记录也会包一层[]，前端取值要写item.author[0]?.username - 不能跨服务空间查询，
from只能填当前数据库里的集合名，大小写敏感
示例（查文章并带上作者信息）：
const db = uniCloud.database()
const res = await db.collection('articles')
.aggregate()
.lookup({
from: 'user',
localField: 'user_id',
foreignField: '_id',
as: 'author'
})
.end()
为什么 $lookup 返回空数组或报错？
常见卡点不在语法本身，而在数据模型和权限配置上。
- 字段类型不匹配：比如
articles.user_id存的是"u123"（字符串），但user._id是自动生成的 ObjectId——这时必须把user._id改成字符串类型，或统一用String(_id)存储 - 安全规则没开读权限：即使 JQL 写对了，
user集合的 permission.read 若设为"auth.uid != null"，而当前请求未登录，就会返回空数组而非报错 - 云函数没部署或名字写错：JQL 必须封装在已上传的云函数中，前端调用
uniCloud.callFunction({ name: 'getArticlesWithAuthor' })，name 必须和云函数文件夹名完全一致 - H5 端漏开本地调试：manifest.json 里没勾选「H5 使用本地云函数」，请求被浏览器拦截，控制台看不到 JQL 报错，只看到 network failed
联表后怎么处理嵌套数据？
JQL 返回的是扁平结构，但 $lookup 带来的 author 是数组，实际使用时容易忽略两层嵌套。
- 前端渲染时别直接写
{{ item.author.username }}，要先判空：{{ item.author[0]?.username || '匿名' }} - 如果需要筛选带作者的文章（比如只查已发布且作者有效的），不能在
$lookup后直接where({ 'author.0._id': { $exists: true } })，得用$unwind展开再过滤——但这会丢掉没匹配到 author 的文章 - 性能注意：每次
$lookup都会触发一次目标集合查询，若 articles 有 100 条，就额外查 100 次 user；数据量大时建议在业务逻辑里分批查，或冗余关键字段（如作者昵称）到 articles 表
真正难的不是写 JQL，而是让两个集合的字段类型对齐、权限开关配对、部署状态同步——这些地方一错，联表就静默失败。
