结论：中间集合比双向引用更可控可维护；双向引用仅适用于轻量、读多写少、接受最终一致的极简场景。$lookup易超时或OOM因未前置$match导致全量扫描，须在foreignField建索引、用$project裁剪字段；双向引用需应用层保障一致性，如$addToSet、bulkWrite清理、分布式锁或唯一索引防重；带业务属性的关系必须用中间集合，并建复合索引；高吞吐场景需分片优化。
直接说结论：别一上来就选双向引用，中间集合（junction collection）在多数真实业务场景里更可控、更可维护；双向引用只适合关联轻量、读远多于写、且能接受最终一致的极简场景。
$lookup 做多对多关联时为什么容易超时或 OOM？
因为 $lookup 默认不做前置过滤，如果主集合没加 $match 就直接 join，MongoDB 会把整个未过滤的主集合文档拉出来，再逐个去被 join 集合查匹配项——尤其当 localField 是数组（比如 user_ids: ["u1", "u2", ...]），它会为每个数组元素发起一次查询，实际是 N 次子查询合并成一个结果数组。内存和网络开销陡增。
- 必须在
$lookup前加$match，缩小主集合输入集，例如{$match: {status: "active"}} - 被 join 的集合（
from）必须在foreignField上建索引，否则每次子查询都是全表扫 - 如果只需要关联数据的几个字段，紧接
$lookup后加$project，例如{$project: {"groups.name": 1, "groups._id": 1}}，避免传输冗余字段 - 单次
$lookup返回的数组长度无硬限制，但若平均每个主文档关联上千条记录，聚合管道极易触发errmsg: "Exceeded memory limit for $group, but didn't allow external sort"
双向引用（A 存 B_id 数组，B 也存 A_id 数组）怎么防脏数据？
靠 MongoDB 自身无法保证一致性——4.0+ 的多文档事务仅限副本集，且不支持跨分片，生产环境用它兜底成本太高。所有一致性逻辑必须压到应用层。
- 新增关联时，用
$addToSet替代$push，避免重复插入同一 ID - 删除主文档前，必须用
bulkWrite批量更新所有关联文档，例如一次性从 500 个groups文档中$pull对应的user_id - 并发写入场景下，两个请求同时给用户 A 添加群组 B，可能都成功写入 B 的
user_ids数组，造成重复——需在应用层加分布式锁，或改用唯一复合索引（如{group_id: 1, user_id: 1}）配合insertOne的upsert: true技巧 - 必须部署定时校验脚本，例如查出所有
groups.user_ids中存在但对应users._id已被删除的记录，这类脚本不能漏跑
什么时候必须拆出中间集合？
只要关系本身带业务属性，或者查询条件涉及关系元数据（时间、状态、权重等），就必须用中间集合。这不是“过度设计”，而是把语义显式落地。
- 典型例子：
user_favorites记录{user_id, article_id, favorited_at, note}——favorited_at支持按时间范围查，“最近收藏”才可索引加速 - 中间集合必须建复合索引，例如
{user_id: 1, favorited_at: -1}或{article_id: 1, favorited_at: -1}，单字段索引无效 - 中间集合里只存
_id引用，绝不嵌入完整用户或文章文档——否则用户改头像，就得批量更新几千条中间记录 - 如果读压力极大且容忍秒级延迟，可用
createCollection + $merge建物化视图，例如预聚合“每个用户最近 20 条收藏”，但得接受后台任务刷新延迟
最容易被忽略的一点：中间集合的写入吞吐量往往比主业务集合还高。比如一个热门文章被万人收藏，一秒内可能产生上千条中间记录插入。这时候单靠默认的 ObjectId 主键和基础索引会成为瓶颈，得提前规划分片键（如按 user_id hash）并压测写入性能。
