一件T恤有5个颜色、6个尺码，后台手工创建就是30个子商品。数量再多一点，人很快会在SKU、颜色或关联关系上出错。可配置商品适合批量导入，但不要从一张空白CSV开始硬写，最好先在后台做出一个完全正确的样板。

导入前先检查变体属性

颜色、尺码等用于变体的属性，需要满足几个条件：作用域为Global，输入类型应是Dropdown、Visual Swatch或Text Swatch等可选类型，并且通常设置为必填。所有要导入的选项值要先存在，例如Red、Blue、S、M、L。

如果CSV写了一个后台不存在的颜色，系统不会替你完整创建好色板、排序和展示标签。先到 Stores > Attributes > Product 检查属性代码和选项，尤其要区分后台显示的“颜色”和真正的属性代码 color。

做一个样板，然后导出来看

在测试环境手工创建一个可配置商品，关联两三个简单商品。确认前台颜色、尺码可选且价格库存正常后，进入 System > Data Transfer > Export，Entity Type选择Products，通过SKU筛选，只导出这个父商品和相关子商品。

打开CSV后，重点看：

  • product_type：子商品是simple，父商品是configurable。
  • configurable_variations：父商品用它记录每个子SKU及对应属性值。
  • configurable_variation_labels：定义前台变体属性标签。
  • 子商品自己的 color、size、价格、库存和可见性。

父子数据应该是什么关系

假设父SKU为TSHIRT-100，子商品为红色S码和红色M码，核心关系可以理解为：

子商品：
sku=TSHIRT-100-RED-S, product_type=simple, color=Red, size=S
sku=TSHIRT-100-RED-M, product_type=simple, color=Red, size=M

父商品：
sku=TSHIRT-100, product_type=configurable
configurable_variations=sku=TSHIRT-100-RED-S,color=Red,size=S|sku=TSHIRT-100-RED-M,color=Red,size=M
configurable_variation_labels=color=颜色,size=尺码

实际CSV应以当前网站导出的格式为准，特别是分隔符。多个变体之间通常使用竖线分开，每个变体内部再用逗号组织参数。如果你的导入页面设置了不同的Multiple Value Separator，文件也要保持一致。

子商品的可见性别设置错

用于可配置商品的简单子商品通常设置为Not Visible Individually，避免搜索结果中同时出现父商品和每个颜色尺码子商品。库存和SKU则放在子商品上，因为真正下单的是具体变体。

父商品通常不需要独立库存数量，但必须关联到正确Website、属性集和分类。父、子商品使用的属性集应包含变体属性，否则即使CSV关系写对，也可能校验失败或前台不显示选项。

新增一个尺码时，不必重新导入全部商品

如果现有商品已有S、M、L，现在只增加XL，可以导出父商品作为基准，创建新的XL子SKU，并在父商品的 configurable_variations 末尾追加新关系。导入文件只保留新增子商品和发生变化的父商品即可。

这样做比重新导入全部旧变体安全，也更容易核对。导入行为选择Add/Update。不要为了省事用Replace，Replace会删除原记录后重建，商品关系、URL和外部系统引用都可能受影响。

校验通过后还要看三件事

  1. 后台父商品的Configurations区域是否列出了所有子SKU。
  2. 前台选择不同颜色尺码时，价格、图片和库存是否切换正确。
  3. 下单后订单项里记录的是否是具体子SKU，而不是只有父SKU。

若前台选项缺失，先检查子商品是否启用、是否分配到同一Website、是否有库存、属性值是否完全一致，再检查索引和缓存。很多时候不是CSV没有导入，而是某个子商品不满足可售条件。

排错时别盯着一整行CSV

把问题拆成三层会更快：第一层是属性和值是否存在；第二层是每个simple商品能否独立保存；第三层才是父商品的关联字符串。先让一个颜色两个尺码成功，再复制扩展，远比一次生成几百个变体容易定位问题。

变体数量太多，关联关系容易出错？

我们可以根据商品主数据生成父子SKU、颜色尺码组合和导入文件，并在测试环境验证前台选择与库存。需要协助时，欢迎联系我们的团队。