MongoDB数组存储自定义对象：选择嵌入还是引用方式？

没有通用的最优解，方案选择完全匹配你的业务读写特性即可，先明确你提到的两种基础方案的适用边界，再补充工业界更常用的折中实现。

两种基础方案的适用场景 #

纯引用方案（仅存储商品ObjectID） #

• 适合的场景：
  • 商品基础信息（名称、价格、分类等）更新频率高，要求所有引用位置实时同步最新商品数据
  • 单用户关联的商品量级大（单用户超过1000条），不会一次性全量拉取所有关联商品
  • 需要反向关联查询（比如统计所有收藏了某款商品的用户列表）
• 你提到的“需要逐个查询ObjectID”的问题完全可以避免：不需要循环发请求，直接用$in操作符就能一次查出所有关联商品：

// 单查询拉取所有关联商品
db.products.find({
  _id: { $in: user.products }
})

MongoDB 3.2及以上版本还支持$lookup聚合，直接在查询用户的阶段完成关联，不需要拆分两次查询。

纯嵌入方案（存储完整商品字典） #

• 适合的场景：
  • 商品数据属于不可变快照，比如用户订单下的商品记录——这类场景下即使后续商品价格、名称调整，也不能篡改用户下单时刻的交易数据，必须保留当时的商品状态
  • 单用户关联的商品量级极小（比如购物车最多存几十件），读请求远多于写请求，要求拉取用户数据时直接拿到全量商品信息，零额外查询开销
• 缺陷你已经提到：源商品数据更新时，所有嵌入了该商品的用户文档都需要批量修改，数据一致性维护成本极高，不适合非快照类的业务场景。

折中方案：嵌入高频访问字段+保留ID引用 #

绝大多数非快照类的业务场景（比如用户收藏、购物车）都不会走上面两个极端，混合方案是综合性能和维护成本的最优选择：
在用户的products数组中，同时存储商品的源ObjectID，以及列表渲染高频用到的少量核心字段，不需要存储完整商品数据，结构示例如下：

// 用户文档结构示例
{
  // 其余用户字段省略
  "products": [
    {
      "_id": ObjectId("关联products集合的商品唯一ID"), // 保留源引用
      "name": "商品名称", // 列表页高频展示字段
      "price": 99.9, // 列表页高频展示字段
      "cover": "商品封面图URL" // 列表页高频展示字段
      // 商品详情、参数、库存、质量评分等低频访问字段不需要冗余存储
    }
  ]
}

这个方案的优势很明确：

• 拉取用户商品列表时不需要额外关联查询，直接就能拿到列表渲染需要的所有核心字段，读性能和纯嵌入方案一致
• 保留了源商品ID引用，需要查看商品详情时，单次查询即可拿到全量商品数据；如果商品核心信息变更，只需要批量更新所有关联用户数组中对应ID的少量冗余字段即可，维护成本远低于纯嵌入方案
• 一致性可控：冗余字段数量少，可以通过MongoDB Change Stream监听商品集合的变更自动同步，不需要在业务逻辑里写大量冗余更新代码。

快速选型参考 #

• 订单、交易凭证类场景：直接选纯嵌入方案，必须保留历史数据快照
• 收藏、关注类场景，商品更新要求强一致、单用户关联商品量级大：选纯引用方案，配合$lookup做关联查询
• 购物车、常购清单这类列表读频率极高、单用户关联商品量不大的场景：选混合方案即可。

内容的提问来源于stack exchange，提问作者erchis patwardhan