内嵌文档适用于子数据极少更新、几乎不单独查询、总量小且稳定的场景，如用户收货地址；若地址量膨胀或需跨用户查询（如“所有深圳地址”），则应改用objectid引用。
什么时候该用内嵌文档而不是 ObjectId 引用
内嵌文档适合「子数据极少更新、几乎不单独查询、总量小且稳定」的场景。比如用户收货地址列表，每人通常就 3–5 条，每次查用户都顺带要地址，改地址也只在用户上下文里发生。
常见错误现象：address 字段突然膨胀到几百条，或者业务开始要求「查所有住在深圳的收货地址」——这时内嵌就卡住了，MongoDB 无法高效扫描嵌套数组里的深层字段。
- 内嵌文档写入快，但单文档不能超过
16MB，数组长度实际受限于平均单条大小 -
$lookup对内嵌结构无效，想跨文档聚合必须先解构（$unwind），性能损耗明显 - 如果子文档有独立生命周期（比如订单里的商品需参与库存扣减、价格审计），内嵌会让事务和变更追踪变脆弱
引用模式下如何避免 N+1 查询地狱
用 ObjectId 存外键本身很简单，难的是查的时候别发起一堆 find()。别指望应用层手动循环查——延迟高、连接数爆、还容易漏异常处理。
使用场景：评论、日志、订单明细这类可能成百上千条、需要分页/按时间筛选/单独更新的数据。
- 优先用
$lookup+$facet或$merge做一次聚合，而不是在 Node.js/Python 里 for 循环findById - 注意
$lookup的from集合必须建好索引，否则聚合阶段会全表扫——尤其在外键字段上建{ "postId": 1 } - 如果子文档还需按条件过滤（比如「只查已审核的评论」），把条件放进
$lookup.pipeline，别拿到内存再filter()
混合方案：小字段内嵌 + 大字段引用的实际写法
真实业务里很少非此即彼。比如博客文章，标题、摘要、标签这些轻量元数据可以内嵌；但正文内容、历史编辑记录、读者点赞用户列表，就得拆出去。
参数差异体现在 schema 设计和读写逻辑里：
- 文章主文档保留
title、slug、tags、publishedAt，但去掉content和likes -
content单独存articles_content集合，用articleId关联；likes存article_likes，用复合索引{ "articleId": 1, "userId": 1 }防重复 - 查详情时用
$lookup拉content，但分页查列表时完全不拉——列表接口只返回内嵌字段，体积可控
引用模式下更新子文档时的原子性陷阱
MongoDB 的原子性只保证单文档操作。如果你用引用模式，又想「给订单加一条物流轨迹并同时更新订单状态」，千万别拆成两个 updateOne——中间失败会导致状态不一致。
性能影响常被忽略：频繁更新引用子集合，会引发大量索引维护开销，尤其当外键字段没索引时，updateMany({ orderId: ... }) 可能慢到超时。
- 涉及多文档强一致性，要么用 MongoDB 4.0+ 的分布式事务（
session.startTransaction()），要么把关键状态收拢回主文档（如lastTrackingTime） - 别在子文档里存冗余计算字段（比如「评论数」），而要用
$inc原子更新主文档的commentCount字段 - 删除主文档前，必须显式清理关联子文档——MongoDB 不支持级联删除，靠应用代码或 TTL 索引兜底都不够可靠
最易被忽略的其实是查询路径的深度：嵌套三层以上（比如 user.profile.settings.theme）会让索引效率断崖下跌，而引用模式下漏建一个 userId_1_status_1 复合索引，线上慢查就立刻浮现。
