双向关联数组在多数业务中反而降低性能；$lookup配合单向引用更稳定，需前置$match、foreignField建索引、及时$project裁剪字段，且单用户关联超500组易内存溢出。
别迷信“双向关联数组能提高查询效率”——它在绝大多数真实业务里反而拖慢写入、埋下一致性雷，且读取优势只在极窄条件下成立。
为什么$lookup配合单向引用比双向数组更稳
很多人以为双向存 ID（user.groups + group.users）能省一次查，但实际：$lookup只要配置得当，一次聚合就能拿到带分组名的用户列表，而双向数组要维护两处、并发易重复、删用户时还得批量扫 group 集合。
- 必须在
$lookup前加$match，比如{$match: {status: "active"}}，否则主集合全量扫描再逐条去 join - 被 join 的集合（如
groups）必须在foreignField: "_id"上建索引，否则每次子查询都是全表扫 - 用完
$lookup紧跟$project，例如{$project: {"groups.name": 1, "groups._id": 1}}，避免把整个 group 文档拖进结果 - 如果平均每个 user 关联超 500 个 group，聚合管道极易触发
"Exceeded memory limit for $group"
双向数组真正适用的场景极少
它只在满足全部以下条件时才勉强可行：关系无业务属性（比如没有“加入时间”“角色权限”）、读请求远多于写（QPS 写
- 新增时必须用
$addToSet，不能用$push，否则并发写入会塞重复 ID - 删 user 前，必须用
bulkWrite一次性从所有相关 group 文档中$pull对应user_id，N+1 查询会打崩数据库 - 必须部署定时校验脚本，例如查出
groups.user_ids中存在但users._id已删除的脏数据，这类任务漏跑一次就积重难返 - 无法按“加入时间”排序或分页，也无法做“过去 7 天新加入的群组”这类带时间条件的查询
带业务属性的关系必须拆中间集合
一旦关系本身携带字段（比如 user_group 记录了 joined_at、role、is_muted），数组引用立刻失效——MongoDB 数组字段无法对嵌套时间戳建有效索引，也做不了 $gt 范围查询。
- 中间集合（如
user_groups）结构应为：{user_id: ObjectId, group_id: ObjectId, joined_at: Date, role: String} - 必须建复合索引：
db.user_groups.createIndex({user_id: 1, joined_at: -1})支持“某用户最近加入的群组” - 高吞吐场景下，
user_id或group_id可作为分片键，避免热点 - 查询“用户 A 在哪些群有管理员权限”，直接
db.user_groups.find({user_id: ..., role: "admin"})，干净利落
真正容易被忽略的是：中间集合不是“过度设计”，而是把关系语义显式落地。当你开始想“这个关联要不要记个时间”，答案就已经是“必须拆”。
