严格内嵌仅适用于子文档几乎不单独读写、体积小且变更少、查询总连带父文档的场景；否则会拖慢写入、膨胀索引、降低备份稳定性。
什么时候该用严格内嵌（embed）而不是引用（$ref）？
一对一关系中，严格内嵌只在满足「几乎从不单独读写子文档」「数据体积小且变更频率低」「查询总是连带父文档一起获取」时才真正划算。否则看似省了一次查询，实则拖慢写入、增加索引膨胀、让备份/迁移更脆弱。
常见错误现象：users 集合里嵌了 profile，但运营要按 profile.last_login 做定时统计——结果每次扫全量用户，profile 字段白占内存还拖慢 find()。
- 判断依据：看子文档是否被高频独立查询或更新；只要存在哪怕一个这样的场景，就别嵌
- 体积红线：单个内嵌文档超过 10KB 就该警惕，MongoDB 文档上限是 16MB，但实际中 2–3KB 是更安全的日常阈值
- 变更敏感点：比如
address里有geolocation字段，地图服务频繁调用它做范围查询——这时必须拆成独立集合 + 地理索引，不能塞进用户文档
db.collection.findOne() 返回嵌套太深，怎么避免字段冗余？
内嵌结构一旦设计过深（比如 user.profile.settings.theme.colors.primary），不仅代码难读，findOne() 默认返回整条文档，还会把大量无用字段拖进网络传输和应用内存。
使用场景：前端只渲染用户头像和昵称，却收到整个 profile 和 settings 嵌套树。
- 必须用
projection显式裁剪：db.users.findOne({ _id: ... }, { projection: { "profile.avatar": 1, "profile.nickname": 1, _id: 0 } }) - 别依赖默认行为：MongoDB 不会自动“猜”你要什么字段，不写
projection就是全量返回 - 注意空对象陷阱：如果
profile本身为null或缺失，"profile.avatar"投影不会报错，但结果里也不会出现该字段——应用层得兼容这种“字段可能不存在”的情况
拆分成两个集合后，$lookup 性能掉得厉害，怎么办？
拆分后用 $lookup 模拟一对一关联，看似规范，但若没建对索引或没控制管道阶段，很容易从毫秒级变秒级。
错误典型：$lookup 目标集合没在 foreignField 上建索引，或者在 $lookup 后接了 $unwind 再 $match——这会让 MongoDB 无法下推过滤条件，被迫先拉全量再筛。
- 必须确保
foreignField有单字段索引，例如：db.profiles.createIndex({ userId: 1 }) - 把过滤条件尽量前移：不要
$lookup → $unwind → $match，而要$match（在$lookup前）+$lookup（带pipeline参数做目标端预过滤） - 确认是否真需要实时关联：很多场景其实可以用应用层两次查询（带
in批量查）+ 本地合并，比聚合管道更可控
内嵌字段加了 required，为什么插入时还是能存 null？
MongoDB 的 schema validation（如 validator）默认不拦截 null 或缺失字段，除非你显式禁止。所谓“严格内嵌”，不是靠字段名体现的，而是靠校验规则和应用层配合。
常见错误：在集合 validator 里写了 { profile: { $type: "object" } }，但没写 { profile: { $ne: null } }，导致插入 { profile: null } 依然成功。
- 验证必须双管齐下：
$type: "object"确保是对象，$ne: null和$exists: true一起堵住null和缺失 - 注意
$lookup结果为空时，聚合阶段可能生成null值——验证器拦不住这个，得靠应用逻辑兜底 - 驱动层也有坑：某些 ODM（如 Mongoose）的
required: true只在 save 前校验，绕过insertOne就失效；纯 driver 下，validator 是唯一防线
真正卡住优化效果的，往往不是选嵌套还是拆分，而是嵌套之后忘了投影、拆分之后忘了索引、加了校验之后忘了 null 的各种变体。这些点不盯紧，模型再“严格”也挡不住数据歪掉。
