没有“该用哪个”，只有“哪种更适合当前场景”：$lookup适合读多写少、关联稳定、查询固定的场景；应用层join更灵活，易控缓存、分页与权限。
MongoDB 多对多该用 $lookup 还是应用层 join？
直接说结论：没有“该用哪个”，只有“哪种更适合当前场景”。$lookup 是聚合阶段的左外连接，适合读多写少、关联数据稳定、且查询模式固定的场景；应用层分两次查（比如先查 user_ids 再查 posts）更灵活，也更容易控制缓存、分页和权限逻辑。
容易踩的坑是硬套关系型思维——以为加个 $lookup 就等于 SQL 的 JOIN。实际上：$lookup 会把匹配的整个文档数组塞进字段里，如果关联集合很大（比如一个用户有上万条订单），结果体积爆炸，内存溢出或超时很常见。
- 用
$lookup前务必加$match过滤主集合，避免全表扫描后再 join - 被 join 的集合必须建好索引，尤其是
localField和foreignField对应的字段 - 如果只需要关联数据的少量字段（比如只取
name和avatar），在$lookup后跟$project投影，别让整个文档拖慢传输
双向引用（A 里存 B_id 数组，B 里也存 A_id 数组）怎么维护一致性？
MongoDB 不支持事务跨文档强一致（4.0+ 虽支持多文档事务，但仅限副本集，且性能代价高），所以双向引用本质是“最终一致性”设计，靠应用层兜底。
典型错误是删 A 时只清了 A 文档里的 b_ids，忘了去每个 B 文档里删对应的 a_id，导致脏数据堆积。更隐蔽的问题是并发更新：两个请求同时给同一个 A 添加 B，可能重复插入 ID。
- 所有增删操作必须走原子操作：
$addToSet替代$push，$pull替代直接赋值数组 - 删除主文档前，用
bulkWrite批量更新所有关联文档（例如：一次更新 500 个 B 的a_ids字段），避免 N+1 查询 - 定期跑后台任务校验不一致（比如查出所有
B.a_ids里存在但对应A._id已不存在的记录），这类脚本不能省
什么时候该放弃引用，改用中间集合（类似关系型的 junction table）？
当中间关系本身带属性（比如“用户收藏文章的时间”“课程与学生的评分”“订单中商品的数量和单价”），或者关联频次极高、查询维度复杂（如“查某用户过去三个月收藏过哪些技术类文章”），就必须拆出独立集合。
这时候再用数组存 ID 就彻底失控：数组无法建有效索引支持时间范围查询，也无法按中间字段排序或聚合。中间集合不是“过度设计”，而是把关系语义显式落地。
- 中间集合必建复合索引，例如
{ user_id: 1, created_at: -1 }支持按用户查最近收藏 - 不要在中间集合里嵌入完整文档，只存
_id引用，否则更新用户信息时要批量更新所有中间记录 - 如果中间关系极少变更但读极多，可考虑用物化视图（
createCollection+$merge聚合输出）预计算，但得接受几秒延迟
Node.js 驱动里处理多对多返回数据，为什么经常拿到空数组或 null？
根本原因不是代码写错，而是没意识到 MongoDB 的“空关联”默认行为：当 $lookup 没匹配到任何文档时，结果字段是空数组 []；但如果用了 $unwind，空数组会直接让整条文档消失——这是最常被忽略的隐性过滤。
另一个常见原因是 ObjectId 类型没正确转换：req.params.id 是字符串，但数据库里是 ObjectId，直接传进 $match 会导致查不到，进而 $lookup 结果为空。
- 调试时先单独执行
db.collection.aggregate([...])在 shell 里看原始输出，别只信应用层日志 - 用
$ifNull统一空值：例如{ $ifNull: ["$comments", []] }，避免模板渲染时报错 - 在
$lookup后加$addFields计算关联数量：{ count: { $size: "$comments" } }，比前端判空更可靠
