一对一关系在MongoDB中应优先内嵌，即把子文档直接存入父文档，适用于依附性强、不独立存在且数据量稳定的情形；但需警惕16MB文档限制及后续业务演进导致的伪一对多风险。
一对一关系在 MongoDB 中优先用内嵌，不是“可以”，而是“应该”——除非它会导致文档超 16MB 或带来明显维护负担。
什么时候直接内嵌子文档最合理
当被关联的实体天然依附于主文档、不独立存在、且数据量稳定时，内嵌是最干净的选择。比如用户头像 portrait、个人简介 profile、设备配置 settings 这类字段，它们没有自己的生命周期，也不会被其他文档复用。
- 内嵌后查询一次就能拿到全部数据，避免二次
find或应用层 join - 更新原子性有保障：用
$set修改user.portrait.mimetype不会破坏一致性 - 不引入额外索引开销，也不需要维护
ref_id字段
为什么不能无脑内嵌？关键限制是 16MB
MongoDB 单文档硬上限是 16MB，但实际中远未到这个值就该警惕。比如一个用户文档里内嵌了高清头像 Base64 字符串（几 MB）、完整简历 PDF 的二进制字段、以及带缩略图的证件照数组，很容易突破安全阈值。
- 一旦接近 5–8MB，写入延迟和网络传输压力就会明显上升
-
ObjectId字段本身虽小，但大量嵌套层级会让 BSON 序列化/反序列化变慢 - 备份、复制、压缩等底层操作对大文档更敏感，故障恢复时间拉长
什么情况下必须改用引用（Reference）
不是“数据多”，而是“数据可能膨胀”或“需要独立生命周期”时，就得拆出去。典型信号包括：
- 子文档字段本身是可变长二进制（如
data: BinData），且长度不可控 - 该子文档会被多个父文档共享（比如一个
avatar_template被 1000 个用户引用） - 业务要求对该子文档单独增删改查、设权限、加审计日志（如
license文档需独立过期校验） - 你发现经常要
$push/$pop子文档里的数组，哪怕只有一项——说明它正在向一对多滑动
这时用 user.license_id: ObjectId("...") + 单独的 licenses 集合，比硬塞进用户文档更可持续。
容易忽略的细节：_id 类型与索引策略
用引用方式时，别只想着存 ObjectId 就完事。如果引用字段是高频查询条件（比如查所有带有效 license 的用户），必须显式建索引：
db.users.createIndex({ "license_id": 1 })
另外注意：license_id 字段类型必须和目标集合的 _id 类型严格一致。常见坑是目标 _id 是字符串（比如从外部系统导入），而你在用户文档里存了 ObjectId，查出来永远为空。
真正麻烦的从来不是怎么选模型，而是模型定下后，随着业务演进，原来“稳定”的一对一悄悄变成了“伪一对多”——比如头像开始支持历史版本、设置开始按设备类型分片。这时候回溯重构的成本，远高于初期多花十分钟评估边界条件。
