必须用嵌入式文档的场景是：数据天然属于同一事务上下文、读多写少，需保证原子性、总是一起读取且体积可控，如用户profile、订单items与payment_status同写，或详情页高频联合访问的地址与联系方式。
嵌入式文档和引用模型不是“选哪个更好”，而是“在哪种场景下必须用嵌入，哪种情况下不得不引用”。选错会导致查询变慢、更新失败、甚至写入被拒。
什么时候必须用嵌入式文档？
嵌入适用于数据天然属于“同一事务上下文”且读多写少的场景。核心判断标准是：是否需要原子性、是否总是一起读取、是否体积可控。
- 一对少且字段稳定：比如
user文档里嵌入profile（含avatar_url、bio），这类数据几乎不单独更新，也不会膨胀 - 强一致性要求：订单创建时必须同时写入
items数组和payment_status，用嵌入才能保证单次updateOne原子生效 - 高频联合访问：用户详情页每次都要展示地址+联系方式+最近3条订单，嵌入后一次
find就能拿到全部，不用跑 4 次$lookup - 注意上限：嵌入后整个文档不能超过
16MB；数组长度持续增长（如日志、评论）会触发Document too large错误
什么时候只能用引用模型？
引用不是“备选方案”，而是应对特定约束的必要设计。强行嵌入会暴露 MongoDB 的硬限制或引入维护黑洞。
- 一对多且“多”方数量不可控：比如一个
product对应成千上万条评论，嵌入会导致文档爆炸，且每次新增评论都要重写整个大文档 - 多对多关系：用户和标签之间是典型多对多，必须拆成
users、tags、user_tags三个集合，靠ObjectId关联 - 跨集合事务需求：MongoDB 4.0+ 支持多文档事务，但只限于同一个分片内的集合。若业务要求“扣库存 + 写订单 + 发通知”强一致，引用模型配合事务才是正解
- 数据生命周期不同：用户资料长期稳定，但操作日志需按月归档或 TTL 自动过期，分开存储才能独立管理
$lookup 性能到底差多少？
很多人回避引用，是因为怕 $lookup 慢。实际影响取决于三件事：索引、管道阶段顺序、是否用上了 let/pipeline 优化。
- 被关联集合的
_id字段必须有索引——这是默认的，但若用其他字段关联（如user_id），必须手动建索引，否则出现Collection scan -
$lookup要放在$match之后：先过滤主集合再关联，避免为几千条无用记录做关联 - 复杂条件别硬塞进
localField/foreignField：用let+pipeline写子查询，例如只关联“状态为 active 的订单” - 实测：10 万级订单集合，关联 5 千用户，加索引后
$lookup平均耗时12ms；没索引则飙升到850ms+
混合模型才是真实项目里的常态
纯嵌入或纯引用都是教科书假设。生产环境里，一个 order 文档往往既嵌入关键字段（customer_name、shipping_address），又引用 customer_id 和 product_ids ——前者保证快查，后者支持反向追溯和变更同步。
- 嵌入冗余字段要克制：只存查询必需的、变更频率极低的副本，比如
customer_name可以嵌，但customer_balance必须引用，否则余额更新时要遍历所有历史订单 - 引用字段命名要明确：用
customer_ref而非customer_id，避免后续有人误以为是嵌入字段 - 变更通知机制不能少：当被引用文档（如
user）更新时，得有逻辑去刷新所有嵌入了它的父文档，或干脆接受短暂不一致——这得由业务容忍度决定
最容易被忽略的点是：嵌入看似省事，但会让应用层失去对“数据所有权”的清晰划分；引用看似麻烦，却把耦合推给了数据库设计本身。真正难的不是语法怎么写，而是想清楚——这条数据，到底该由谁负责更新、谁负责过期、谁来保证最终一致。
