内嵌文档适合读多写少、数据体积小且强绑定的场景，主键关联适合需独立索引或事务的场景，混合模式兼顾性能与扩展性，但需保障数据一致性。
内嵌文档适合读多写少、数据体积小的场景
当两个实体天然强绑定、从不单独存在，且关联数据不超过 16MB（MongoDB 单文档上限），内嵌是最直接的选择。比如 User 和 Profile，其中 Profile 永远只属于一个 User，字段稳定（头像 URL、昵称、简介），更新频率低——这时把 profile 字段作为子文档塞进 User 文档里，一次 find() 就能拿到全部信息，省去二次查询开销。
但要注意：如果内嵌字段频繁更新（比如计数器、日志列表），每次修改都会触发整个父文档重写，可能引发写放大；更隐蔽的问题是，$set 更新深层嵌套字段（如 profile.avatarUrl）时，若路径不存在，MongoDB 不会自动创建中间层级，容易静默失败——务必确保初始数据结构完整或用 $setOnInsert 配合 upsert。
主键关联（$lookup）更适合可变、需独立索引或跨集合事务的场景
用 ObjectId 引用另一集合（如 User 中存 addressId: ObjectId("...")，Address 独立成集），本质是模拟关系型数据库的外键。它不强制要求数据共存，支持对 Address 单独建索引、设置 TTL、做变更流监听，也允许在分布式事务中安全地更新双方。
性能上，单次 $lookup 在 4.2+ 版本默认走内存哈希连接，只要被关联集合有对应索引（如 Address._id 上的默认索引），延迟增加通常在毫秒级；但若高频调用且未加缓存，网络往返 + 聚合阶段解析会累积可观开销。常见坑是忘记在 pipeline 中加 $limit: 1，导致 MongoDB 尝试拉取所有匹配文档再裁剪，白白消耗内存。
实操建议：
- 关联字段命名统一用
xxxId（如profileId），避免和内嵌字段名混淆 -
$lookup的from集合名必须全小写、不含特殊字符，否则驱动报CommandNotFound - 若关联目标偶尔为空，用
$lookup+$unwind: { path: "$address", preserveNullAndEmptyArrays: true }保底
混合模式：内嵌基础字段 + 主键引用扩展数据
真实业务常卡在中间态：既要快速读取常用字段，又得支持扩展和独立管理。典型做法是拆分“热数据”和“冷数据”。例如 User 文档内嵌 name、email、avatarThumbnail（高频展示），同时保留 profileId: ObjectId(...) 指向完整 Profile 集合，里面存富文本简介、历史编辑记录等大字段。
这种设计让首页列表页走内嵌，详情页按需 $lookup，但代价是应用层逻辑变重——你得确保两处数据的一致性。MongoDB 本身不提供级联更新，必须靠应用代码或 Change Stream + 后台任务同步。最容易被忽略的是：当用户删掉 Profile 文档后，User.profileId 变成悬空引用，后续 $lookup 返回空对象，前端若没判空就直接取 profile.bio，会抛 TypeError: Cannot read property 'bio' of null。
压测前必须验证的三个边界点
选型不能只看理论，得用真实数据跑。重点盯住这三个点：
- 内嵌文档平均大小是否逼近 2MB？超过后 BSON 序列化/反序列化耗时明显上升，Node.js 驱动里
JSON.parse()开销会跳变 - 主键关联场景下，
$lookup的localField是否已建索引？没索引时聚合可能扫全表，explain("executionStats")里totalDocsExamined会暴增 - 混合模式中，同一业务操作（如“编辑用户资料”）是否同时触发内嵌字段更新 + 外部集合更新？事务
session.startTransaction()必须包裹全部操作，漏掉任意一步都可能造成数据撕裂
没有银弹。内嵌不是“快”的代名词，主键关联也不等于“慢”。真正影响性能的，往往是索引缺失、驱动配置不当（如 Node.js 的 maxPoolSize 设太小）、或应用层没做连接复用——这些比选型本身更容易出问题。
