如何在Firestore DB中存储商品附加项

完全不需要为每个附加项单独创建数据库条目，90% 以上的场景下直接内嵌到现有商品文档就足够，不会产生额外接口调用成本。

方案1：内嵌附加项数组（优先推荐） #

直接在原有商品文档中新增附加项配置字段，Firestore 单文档最大支持 1MB 存储，足以容纳数百条附加项信息，查询时一次读取就能拿到全量配置，零额外成本。
修改后的商品结构如下：

{
   "itemName": "经典意式披萨",
   "itemBasePrice": 59,
   "itemStock": 120,
   "availableAt": ["国贸店", "中关村店"],
   // 附加项配置
   "itemAddons": [
      {
         "addonId": "cheese_extra",
         "addonName": "额外芝士",
         "addonPrice": 8,
         "maxSelect": 2, // 最多可加份数
         "isAvailable": true
      },
      {
         "addonId": "pepperoni",
         "addonName": "意大利辣肠",
         "addonPrice": 12,
         "maxSelect": 1,
         "isAvailable": true
      }
   ],
   // 可选：附加项分组配置，用于前端分类展示（比如加料区、饼底选择、酱料选择）
   "addonGroups": [
      {
         "groupId": "topping",
         "groupName": "加料选择",
         "addonIds": ["cheese_extra", "pepperoni"]
      }
   ]
}

该方案优势：

• 无额外调用成本：一次商品查询即可拿到全部附加项信息
• 维护成本低：新增/修改/下架附加项仅需要更新对应商品的单个文档
• 灵活性高：可自定义附加项限购数量、可用门店、库存限制等扩展字段

方案2：公共附加项复用库（适合多商品共享附加项场景） #

如果同款附加项需要关联多个商品（比如所有饮品都支持加珍珠、椰果），可以单独建立公共附加项库避免重复存储：

1. 新建根级集合 addons，存储所有通用附加项信息，单文档结构如下：

{
  "addonId": "bubble",
  "addonName": "珍珠",
  "addonPrice": 3,
  "isAvailable": true,
  "stock": 1200 // 支持附加项独立库存管理
}

2. 商品文档中仅存储关联的附加项 ID 列表：

{
  "itemName": "原味奶茶",
  "itemBasePrice": 18,
  "itemStock": 200,
  "availableAt": ["全部门店"],
  "linkedAddonIds": ["bubble", "coconut", "grass_jelly"]
}

该方案查询仅需要2次调用：1次读取商品文档，1次用 Firestore 的 in 查询批量读取关联的附加项文档，单次 in 查询支持最多10个匹配条件，完全覆盖绝大多数商品的附加项数量需求，成本极低。附加项信息修改后全局生效，不需要逐一更新关联商品。

仅需单独创建附加项文档的场景 #

只有当附加项需要独立的复杂业务逻辑时，才需要单独存储：

• 附加项需要独立库存管理（比如某款配料卖完后，所有关联商品都自动下架该附加项）
• 附加项需要单独统计销量、做独立数据分析
• 单个商品的附加项超过200个，内嵌会导致单文档体积过大
  即使是这种场景，也不需要调用上百次接口，用批量查询即可，100个附加项仅需要10次调用，成本可以忽略。

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