子文档数量应稳定可控，优先看addresses而非orders；嵌入仅适用于一对少、数量明确且增长有限的场景，如收货地址或标签，而订单等无上限数据必须引用。
子文档数量是否稳定且可控？看 addresses 还是 orders
嵌入只适合「一对少」且数量明确的场景。比如用户收货地址，通常不会超过 10 条；文章标签一般也就 3–5 个。这种数据写入后极少新增，读取时又总是一起展示——嵌入能省一次查询。
但如果你面对的是订单、评论、课程章节这类天然增长无上限的数据，orders 数组塞到用户文档里，迟早触发 DocumentTooLarge 错误（16MB 限制）。哪怕当前只有几十条，业务一扩张就崩。
- 用
db.users.findOne().addresses.length快速估算子项数量，若平均 >20 或方差极大（有的用户有 2 条，有的有 200 条），别嵌入 - 子文档本身含二进制字段（如
thumbnail、transcript）时，即使数量少也建议引用，避免单文档膨胀 - 别依赖“现在不多”做决策——查下历史日志：过去 3 个月，该类子数据月均增长量是多少？
读取模式是否总是“父+全部子”一起查？警惕 $elemMatch 和 arrayFilters 的陷阱
嵌入看似省查询，但一旦你开始按子文档条件筛选（比如“查所有 status 为 pending 的订单”），就得靠 $elemMatch 或 arrayFilters。它们不能高效利用索引，性能随数组长度线性下降。
-
db.users.find({ "orders.status": "pending" })会扫描整个orders数组，无法跳过不匹配项 - 想对子文档字段排序（如按
orders.createdAt倒序取前 5 条），嵌入方案必须加载全部子文档再内存排序，而引用方案可直接db.orders.find({ user_id: ... }).sort({ createdAt: -1 }).limit(5)走索引 - 聚合管道中用
$unwind拆开嵌入数组，数据量大时内存和 CPU 开销陡增，不如原生集合查询
子文档是否需要独立生命周期或被其他集合引用？检查 ObjectId 类型与索引
如果子数据要单独更新、删除、审计，或被第三方系统（如支付、通知服务）直接消费，它本质上已不是“附属”，而是实体。这时硬嵌入会破坏单一数据源原则。
- 引用字段必须存为原生
ObjectId，而非字符串"507f1f77bcf86cd799439011"—— 否则db.orders.createIndex({ user_id: 1 })无效，find({ user_id: ... })变全表扫描 - 子文档若需被多个父文档关联（如一条日志被多个报警规则触发），只能用引用；嵌入无法表达多对一或多对多
- 事务需求明确时（如“扣款 + 更新订单状态 + 发通知”原子性），MongoDB 多文档事务仅支持引用模型下的跨集合操作
业务演进是否已暴露嵌入瓶颈？别等 Document is larger than 16MB 报错才改
很多团队在 MVP 阶段嵌入一切，等上线半年后发现课程文档里塞了视频元数据、测验题干、学生作答记录，单文档逼近 15MB，此时重构成本远高于初期设计。
真正关键的信号不是“现在能不能跑”，而是“下次加一个功能，模型要不要动手术”。比如平台要支持课程回放倍速设置，这个字段该加在哪？如果加在课程文档里，所有已有课程都得批量更新；如果加在 lessons 集合里，只需改 schema 设计，不影响存量数据。
最容易被忽略的一点：嵌入和引用不是静态选择，而是随业务阶段动态调整的接口契约。早期嵌入图快，中期拆分引用保扩展，后期可能混合使用（如热门课程预热数据嵌入，冷门课程按需引用）——重点在于每次变更时，明确数据所有权和更新边界。
