带变体与捆绑的产品目录：模式与 UI 模式

为什么变体和捆绑会很快变得混乱

当每件产品只有一个价格和一个库存时，目录看起来很简单。加入颜色、尺码、订阅长度或按地区不同的包装后，这种简单性就会崩塌。单表“Products”再也不能回答一些基本问题：我们到底在卖哪一个具体商品？我们如何跟踪它？

购物者也期望细节准确无误。他们想选项可选、价格立刻正确显示，并且知道所选组合今天能否发货。如果页面写着“有现货”但选中的尺码已经没有了，信任会快速下降。如果价格只在结账时改变，售后工单和退货就会随之而来。

捆绑给事情增加了第二层复杂性：它看起来像产品，但表现像规则。“入门套装”可能包含一瓶、一只泵和一组滤芯。它的可用性取决于组成部件，而且你的成本和报表仍然需要合理。

下面这些是目录开始出现裂痕的迹象：

• 你为了表示一个选项而创建重复的 SKU。
• 捆绑销售后库存数字看起来不对。
• 管理后台屏幕变成了一长串近似相同的条目。
• 折扣和税对单品有效，但对套件失效。
• 报表无法回答“实际卖出了什么？”

解决方法主要是自律：一个保持一致的数据模型，以及能让顾客和团队一眼看出选项与可用性的 UI 模式。

通俗术语：选项、变体、SKU、捆绑

当人们说“变体”时，常常把几种不同的概念混在一起。早期把词弄清楚会让后面的决策（模式、UI、库存）容易得多。

大多数团队使用这些定义：

• 选项（Option）：购物者可以做出的选择，比如尺码或颜色。
• 选项值（Option value）：选项内的一个值，比如 Size = M 或 Color = Black。
• 变体（Variant）：一组选项值的精确组合，比如 Size M + Color Black。
• SKU：一个可售单元，你在运营和库存中跟踪。变体常常映射到一个 SKU，但并非总是如此。
• 捆绑 / 套件 / 多件装：由其他产品组成的商品。捆绑通常是营销上的组合（部件可以单独出售）。**套件（kit）**是必须一起发货的组合。**多件装（multipack）**是相同商品的重复（例如 3 双袜子装）。

在实践中，ID 也会混淆。内部 ID 是数据库用的。SKU 是你的运营编码（用于拣货、补货和报表）。条码（UPC/EAN）是扫码器读到的。一种 SKU 可以有多个条码（不同地区），有些商品甚至没有条码。

判断是否应作为可售变体的好规则：如果它可能有不同的价格、库存、重量或运输规则，就把它当作可售项。相同的 T 恤在 Size M 和 Size XL 通常需要单独库存计数，所以应该是独立的 SKU。

决定你的目录需要支持什么

在选择模式前，先从业务每天必须回答的问题开始。当有人查看一件商品时，你能否自信地说：它现在可用吗？多少钱？如何发货？适用什么税率？

一个有用的方法是决定每个“事实”该放在哪里。把共享的事实放在 Product，把会变化的事实放在 Variant（SKU）。如果把它们混在一起，你会在两个地方修同一个 bug。

通常决定字段归属的问题包括：

• 如果它随尺码/颜色/材质变化，就放在变体上。
• 如果对所有选项组合都成立，就放在产品上。
• 如果按 SKU 报表（销售、利润、退货），就按变体存储。
• 如果运营用它来拣货/打包/发货，就放在仓库实际使用的位置：SKU 上。
• 如果可以安全地派生（例如从选项值生成显示名称），就只存源数据并派生显示值。

保持单一事实来源。例如，除非角色明确（比如产品有 MSRP，变体有实际售价），否则不要在产品和变体上都存“价格”。

为变化做计划。你可能以后添加新选项（比如“长度”）、停用一个变体，或在供应商变化后合并 SKU。当变体是第一类记录而不是标签时，这些操作会更顺利。

如果你在 AppMaster 中构建，Data Designer 里清晰的实体命名能让随着需求变化的维护更容易。

一个实用的产品与变体数据库模式

一个清晰的模式可以在简单商品变成数十个可售组合时保持目录可理解。目标是把购物者做出的选择（他们挑的）与你实际库存和发货的可售单元分离建模。

一组可靠的实体包括：

• Product：父级商品（名称、描述、品牌、分类、默认图片）
• Option：一种选择类型（Size、Color）
• OptionValue：允许的值（Small、Medium、Red、Blue）
• Variant：可售单元（一个选项值组合）
• VariantOptionValue：连接 Variant 与其选中 OptionValues 的关联表

变体唯一性是许多目录出错的地方。最安全的做法是规范化：对每个 Variant 强制每个 Option 只有一个 OptionValue，并防止重复组合。如果也想兼顾速度，可以在 Variant 上存一个计算出的“variant key”，例如 color=red|size=m（或它的哈希），并在 Product 范围内将其设为唯一。

把随组合变化的字段放在 Variant 上，而不是 Product：SKU、条码、价格、对比价、成本、重量、尺寸、状态（激活/停产）、以及图片（一个主图或小图库）。

对于自定义属性（比如“材质”或“保养说明”），避免不停地加新列。在 PostgreSQL 中把这些放到 Product 或 Variant 的 JSONB 字段里效果很好，配合应用层的小型校验层。

保持长期一致的 SKU 规则

SKU 是你承诺保持稳定的可售单元标识。它应该回答一个问题：“我们卖的究竟是哪一件？”它不应该试图承载营销名称、完整选项文本、季节或一整段故事。如果你把太多含义塞进去，后来任何变更都会在不破坏报表的情况下变得困难。

早点决定 SKU 是人工分配还是自动生成。已有 ERP、条码或必须匹配的供应商 SKU 时，人工 SKU 更安全。变体很多且需要一致性时，生成 SKU 更安全，但前提是规则不会在年内变动。常见的折衷是使用你控制的固定基础 SKU，加上为变体属性生成的短后缀。

可读且能随增长保留的规则：

• 一旦订单使用了某个 SKU，就保持该 SKU 稳定。不要通过重命名来“修正”旧 SKU。
• 把内部 ID 和 SKU 分离。用 SKU 给人看，用 ID 给数据库用。
• 使用短前缀表示产品家族（例如 TSH、MUG），不要用完整单词。
• 避免会变意义的内容（比如“2026”或“SUMMER”），除非你的业务确实这样运作。

停产 SKU 不应该被删除。标记为非激活，保留其价格历史，并在过去的订单、退款和报表中可选。如果你替换了一个 SKU，存一个“被替换为”的引用，以便支持可以追溯发生了什么。

校验规则可以防止随时间慢慢出现的问题：在所有可售项中强制 SKU 唯一，只允许字母、数字和连字符，设置明确的最大长度（通常 20-32 字符），为特殊情况保留前缀（例如“BND-”用于捆绑）。在 AppMaster 中，这些检查适合作为数据约束加上阻止违反规则的业务流程。

超越简单有货/缺货的库存逻辑

当同一“产品”可能代表许多不同的可售单元时，库存会变得令人困惑。在写规则之前，先选定你的库存单位：你在产品级别、变体级别，还是两者都跟踪库存？

如果客户会选择尺码或颜色，变体级别的库存通常最安全。某款衬衫整体“有货”，但 Small-Blue 变体可能已售罄。产品级库存适合变体并不改变实际存储方式的商品（例如不同计费方案的数字许可）。有些团队两者兼顾：产品级用于报表，变体级用于销售。

防止超卖不是靠一个魔法开关，而是靠清晰的状态。大多数目录最终需要预留（为购物车或未付款订单临时保留库存）、备货（允许有明确发货日期的销售）、库存缓冲（一个隐藏数量覆盖同步延迟）和原子更新（在确认订单时同一操作减少库存）。

“神秘库存”通常来自边缘案例。退货应在检验后才把库存加回，而不是在创建退货标签时。损坏的商品应移到单独状态或位置，这样它们不会显示为可售。库存调整需要审计轨迹（谁在什么时候为什么改了什么），尤其是在多个渠道更新库存时。

捆绑和套件有一个关键规则：如果捆绑只是一个分组，不要减少“捆绑”记录的库存。应该减少组成部件。3 件装应减少同一 SKU 的 3 个单位；套件应减少每个组件 1 个单位。

例如：一个“入门套件”包括 1 瓶和 2 个滤芯。如果你有 10 瓶和 15 个滤芯，套件可用数量是 7，因为滤芯是限制项。基于组件的计算能让报表、退款和补货保持一致。

在 AppMaster 中，这可以在 Data Designer 的变体表和 Business Process Editor 的预留/扣减逻辑中清晰映射，使每次结账遵循相同规则。

在不破坏报表的情况下建模捆绑和套件

捆绑是目录常常进入特例区域的地方。最简单的做法是把捆绑建模为普通的可售项，然后附上清晰的组件列表。

一个干净的结构是：Product（可售项） 加上 BundleLines。每条 BundleLine 指向一个组件 SKU（或一个组件产品加上所需变体），并存储数量。订单仍然显示“一个项目”，但在需要成本、库存和履单细节时你可以把它展开成部件。

大多数捆绑设置属于下面几种：

• 固定捆绑（kit）：组件和数量恒定。
• 可配置捆绑：顾客可以从允许的组件中选择（仍然在订单上保存为行项）。
• 虚拟捆绑：营销分组（通常不影响库存），用于商品陈列而不影响履单逻辑。

定价是团队容易把报表搞乱的地方。提前决定什么显示在订单行上，什么用于利润和库存报表。常见方法有固定捆绑价、按部件相加，或按折扣后的部件总和（例如“任选 3 件，最低价半价”）。

库存也要同样严格：只有当每个所需组件都满足数量时，套件才可用。为报表起见，保存销售的两个视图：

• 售出项目：捆绑 SKU（用于收入、转化和陈列）。
• 被消耗组件：展开的 BundleLines（用于库存移动、销货成本和拣货单）。

在 AppMaster 中，这自然适配：一个 Bundle 表加上 BundleLine 行，并在结账时用 Business Process 展开组件，同时在一个事务中写入捆绑销售和组件消耗记录。

选择选项与变体的 UI 模式

好的选项 UI 能让人顺利完成购买。糟糕的选项 UI 会让人猜测、遇到错误然后离开。关键是让购物者尽早定位到一个真实、可购买的变体，同时明确展示他们的选择会改变什么。

面向客户：先选项，再变体

一个可靠的模式是先展示选项（Size、Color、Material），然后只展示仍然有效的选项值。

不要让顾客随意选择任意组合然后在加购物车时才失败。用户做出选择后，应立即禁用不可能的组合。例如，选了 Color = Black 后，不存在 Black 的尺码应变为不可用（而不是直接移除），这样顾客能理解哪些不可用。

随着选择变化，更新最重要的部分：价格（含促销价和任何捆绑折扣）、主图（匹配所选颜色或样式）、库存状态（精确到变体，而不是泛泛的产品库存）、预计送达时间（若随变体变化），以及可选地显示 SKU 或“产品编码”以供客服使用。

让界面保持冷静。一次只展示少数选项组，避免当色板或按钮更有效时使用巨大的下拉菜单，并让当前选择明显可见。

面向管理员：像电子表格那样编辑变体

在后台，人们需要速度而不是漂亮卡片。变体网格非常合适：每行是一个 SKU，每列是一个选项或规则（价格、条码、重量、库存、激活/停用）。增加批量操作以便于常见任务（例如价格更新、切换可用性或分配图片）。

如果你在 AppMaster 中构建，一个实用设置是把网格绑定到你的 Variant 表，配上过滤器（选项值、激活状态、低库存），并加上在保存前校验规则的批量更新动作。

逐步流程：变体选择与捆绑可用性检查

选择流程看起来应该很简单，但底层需要严格规则。目标是始终知道购物者正在配置的确切 SKU，以及它现在是否可购买。

变体选择（单个商品）

加载的不应只有产品名和图片。你需要完整的选项值集合（Size、Color）以及存在的有效变体组合列表。

一个可靠流程：

1. 拉取产品、它的选项以及所有已存在的变体（或一张压缩的有效组合映射）。
2. 存储购物者当前的选择（例如：Size=M, Color=Black），并在每次点击时更新。
3. 每次变化后，通过将选中选项值与变体列表比较来查找匹配的变体。
4. 如果有匹配且可购买（激活、价格已设置、未被阻止），启用“加入购物车”。
5. 如果没有匹配，保持“加入购物车”禁用并引导购物者选择有效组合。

一个防止挫败感的小 UI 细节：在早期选择后立即禁用不可能的选项值。如果 Size=M 只存在于 Black，那么一旦选了 M，其他颜色应显示为不可用。

捆绑可用性（由组件构成的套件）

对于捆绑，“有货”不是一个单一数字。它取决于组件。通常规则是：

bundle_available = minimum over components of floor(component_stock / component_qty_per_bundle)

例如：一个“入门套件”需要 1 瓶和 2 个滤芯。如果你有 10 瓶和 9 个滤芯，可用套件数是 min(floor(10/1)=10, floor(9/2)=4) = 4。

错误信息应具体。更喜欢 “仅有 4 套可售（滤芯限制了此捆绑）” 而不是 “缺货”。在 AppMaster 中，这种检查可以在 Business Process 里表达得很直接：先计算匹配的变体，再计算捆绑限制，最后返回给 UI 一个清晰的状态供展示。

常见错误与陷阱

当你为“可能存在的一切”建模，而不是为“你实际会卖的东西”建模时，目录就会出问题。最迅速把自己逼入死角的方法是在前期生成所有可能的选项组合，然后随着目录增长再想办法清理。

为永远不会备货的变体创建记录是经典陷阱。如果有 4 种颜色 × 6 个尺码 × 3 种材质，那就是 72 个变体。如果只有 10 个会被实际售出，剩下的 62 条记录会造成混乱、引发错误并拖慢报表速度。

定价是另一个安静但危险的出问题来源。当同一价格分散在多个地方（产品、变体、价格表、促销表）而没有单一事实来源时，问题就会出现。一个简单规则是：一次存基础价，只在真正需要时存覆盖（例如某个变体有不同价格）。

捆绑和套件在库存上会失败的常见原因是同时扣减捆绑和其组件。如果你卖了一个包含 1 瓶和 2 个滤芯的“入门套件”，同时减去 1 个套件记录又减去 1 瓶和 2 个滤芯会导致库存过早归零。把捆绑当作可售项，但从组件计算可用性和扣减。

后台工具会造成破坏，如果它们允许无效数据。及早加入护栏：

• 阻止重复 SKU，即使在已归档的项目中也要如此。
• 要求每个变体拥有所有选项值（不能出现“缺少尺码”）。
• 防止两个变体共享相同的选项组合。
• 校验捆绑组件（不允许零数量，不能缺少 SKU）。

最后，为变化做计划。稍后添加新选项（比如鞋子的“宽度”）是一次迁移，不是一勾选。决定现有变体的处理方式、默认值如何设置，以及旧订单如何保留原始 SKU 与选项快照。

发版前的快速检查

在上线前，检查那些在真实环境中会坏的点：找到 SKU、更新库存以及阻止不可能的购买。

确保每个可售 SKU 都容易被找到。搜索应能按名称、SKU 代码、条码/GTIN 和关键属性（如尺码或颜色）找到。如果仓库使用扫码，测试几个实物扫描并确认它们定位到确切 SKU，而不是仅到父产品。

严格规定库存变更发生的位置。选一个事实来源（你的库存移动逻辑），确保所有事件都使用它：订单、取消、退款、人工调整和套件组装。如果库存能在两个屏幕或两个工作流中被编辑，漂移是必然的。

值得运行的上线检查：

• 在 UI 中选择选项并确认无效组合在加购物车前就被阻止，而不是在结账时才发现。
• 对于捆绑，确认可用性由最稀缺的组件和正确的数量驱动（例如每套需 2 个电池会把可用数减半）。
• 停用一个 SKU 并验证它从浏览和搜索结果中消失，但仍在过去的订单、发票和报表中正确显示。
• 下一个测试订单，取消它，然后再下单；库存应正确返回并被重新预留。

如果你在 AppMaster 中构建，把库存更新规则放在一个 Business Process 中并从所有路径调用它。这个单一习惯能防止大多数库存错误。

示例场景与实用后续步骤

想象一家还需要完善目录的服装店。

你卖一款 T 恤，有两个选项：Size（S、M、L）和 Color（Black、White）。每个可购买的组合都是一个独立的变体，拥有自己的 SKU、价格（如需要）和库存。

在模式中，为“Classic T-shirt”保留一个 Product 记录，两个 Option 记录（Size、Color），以及若干 Variant 记录。每个 Variant 存储其选中的选项值（例如：Size=M, Color=Black）和 SKU（例如：TSH-CL-M-BLK）。库存在变体级别跟踪，而不是产品级别。

在 UI 上，收窄选择并防止无效路线。一个清晰的模式是：先展示所有颜色，然后仅显示所选颜色存在的尺码（或反过来）。如果“White + L”不存在，不能选择它，或以禁用状态并带明确说明显示。

现在加入一个捆绑：“礼品套装”包含：

• 1x Classic T-shirt（任意变体）
• 1x Sticker pack（简单 SKU）

捆绑的可用性受最紧缺组件限制。如果 Sticker pack 的库存是 5，即使 T 恤库存充足，你也不能售出超过 5 套。如果捆绑需特定 T 恤变体（例如 Black M），则捆绑库存为 min(StickerPackStock, BlackMStock)。

在 AppMaster 中的实用后续步骤：

• 在 Data Designer 中构建表（Products、Options、OptionValues、Variants、VariantOptionValues、Inventory、Bundles、BundleComponents）。
• 在 Business Process Editor 中实现“查找有效变体”与“计算捆绑可用性”。
• 从同一项目生成 Web 与原生移动 UI，在所有地方使用相同的变体过滤和可用性规则。

如果你想快速端到端原型，AppMaster (appmaster.io) 旨在构建带有真实业务逻辑的完整应用，这正是变体选择与捆绑库存规则所依赖的功能。