Shopify 汽配适配表：逐行录入车型资料并验收展示

汽配商家拿到供应商适配表后，先要保留“同一行里同时成立的车型条件”，再决定哪些资料能展示给顾客。年份列表与发动机列表分别有值，不代表两者的所有组合都适配。本文完成一个小范围交付：把已审核的适配行录入 Shopify 元对象，关联到一个明确的商品，再验收页面是否逐行保留条件与限制。保存资料不会自动建立车型匹配引擎，也不构成安装安全认证。

开始前，把适配行与可售 SKU 分开

准备供应商原始资料、版本或日期、行号、适用市场、车型、年份、发动机、安装位置、明确限制，以及内部复核记录。先确认这份资料对应哪个实际可售 SKU、单件还是套装。供应商件号相同而包装或左右位置不同的货品，不能仅凭件号把适配表挂到所有商品上。

Auto Care 的 ACES 标准用于传递车辆适配信息；PIES 侧重商品信息。两者都不是可直接取用的全行业商品数据池。标准格式也不能替代供应商对某个零件适用范围的证据。这里处理商家已有的资料，不声称 Shopify 原生解析 ACES、自动识别 VIN 或认证车辆兼容性。ACES 官方说明、PIES 官方说明。

下面全部是虚构练习资料，车型、件号和审核结果不对应真实车辆或零件，也未进行安装测试、后台操作或主题运行。假设商品只有一个可售 SKU AP-R-F-01，包装为单件；复核人员已在练习中认可下列两行的资料完整性。

这张表没有“2019 年＋E20”的记录。即使页面同时出现了 2019 和 E20，也必须把该组合标为未证实，需人工核对。也不要把“2019、2020”擅自延伸为其他年份。真实资料缺少发动机、市场或限制说明时，先向资料负责人补齐；未核实行不进入已核准展示。

用一条元对象记录保存一整行

在后台进入 Content > Metaobjects > Add definition，新建 Fitment row 定义。逐个 Add field，选择类型并写清录入说明；保存前检查后台实际生成的字段 key。本文用的 key 是写作者设计的命名，不是 Shopify 预置的汽配字段。定义与多个字段的创建方式见官方元对象定义步骤。

为避免代码与字段错配，练习时可把表中的英文 key 用作 Field label，再核对后台实际 key；若不同，修改代码对应访问名后再测试。点击 Field label 旁的星号，把必需字段设为必填；展开字段行的 Description 填写输入说明与复核负责人，最后点击 Save。字段的必填或类型校验只能检查录入格式，不能判断车型关系是否真实。保密原表和审核文件留在受控资料库；元对象中的来源标识只保留允许公开的部分。

进入 Settings > Metafields and metaobjects，选择元对象所属部分及 Fitment row 定义，在 Options 中启用 Active-draft status，并为计划展示的定义开启 Storefronts 访问，点击 Save。访问权限应按整份公开数据检查；不要因为主题只显示几个字段，就把私密字段也存进可供 storefront 访问的定义。Active/Draft 是平台发布状态，和本例的 review_state 文本字段是两回事。官方选项与访问说明。

进入 Content > Metaobjects > Fitment row > Add entry，先建立 F01，再建立 F02。把表格每一行完整转写到各自的 public_summary；创建时先设为 Draft，保存并逐行与原表核对。练习可把复核日期填为 2026-10-03，这仍是虚构日期；真实条目必须使用实际复核完成日期。真实数据审核通过后，才填写“资料已核准”、真实复核日期并按需要改为 Active。官方说明，新条目默认可能是 Active；不能假定新建就自动隐藏。开启发布状态能力后，Draft 条目在 Liquid 中不可用，Active 条目才可访问。条目录入与状态步骤、Liquid 元对象发布状态。

将行清单关联到正确商品

进入 Settings > Metafields and metaobjects > Products > Add definition。名称填“适配资料行”，检查并将 namespace/key 设为 custom.fitment_rows，类型选 Metaobject，关联刚建的 Fitment row 定义；将 One value 改为 List of values，按展示需要开启 Storefronts，保存。这里需要列表，因为一个商品可能有多条适配行；只选单值会丢掉另一行。官方关联元对象步骤、自定义元字段标识规则。

打开目标商品，在 Metafields 区域选择“适配资料行”；未显示时点 Show all。Select entry 选择 F01、F02并保存。核对商品实际 SKU 与原表映射，不用相似商品标题代替确认。这个示例只覆盖一个 SKU。若同一商品的多个变体具有不同适配范围，不能把商品级清单解释为所有变体都适用；先另行解决逐变体关联与展示，再上线。

先在独立测试店或受控试验商品上验证。修改已发布元对象条目可能立即影响所有引用它的位置；未发布的主题副本不能隔离共享的数据变更。官方条目修改影响说明。

在主题中逐行显示，而不是只显示“支持车型”

进入 Online Store > Themes，为选定的主题副本打开 Edit theme，选择商品模板和试验商品。兼容的区块可用 Connect dynamic source 连接元对象字段，但字段类型、模板资源与区块设置必须匹配；列表引用不保证当前主题能直接完整渲染。先预览实际结果，不能把后台保存成功当成页面已显示。官方主题连接条件。

若主题的 Add section 中提供 Custom Liquid 区段，可在该区段的代码输入处试放下面的展示样例并保存主题副本。可用区段取决于主题及其版本；没有这一选项时，停止套用本步骤，把字段 key、预期输出与下面的验收表交给主题开发者。不要猜测另一个区段也接受 Liquid。官方区段添加步骤、官方 Custom Liquid 可用条件说明。

**下面代码未运行，也未在任何实际主题测试。**它只遍历商品的列表引用，按本例约定的状态文字显示公开字段；不计算适配、不检查 VIN、不验证原始资料。使用前核对真实 namespace、key 与字段 key。.value 获取元字段及元对象字段的值，列表可逐项遍历；文本输出做转义。Liquid 元字段对象、Liquid 元对象字段。样例先使用 escape 转义文本，再用 newline_to_br 保留多行说明的换行。

{% assign rows = product.metafields.custom.fitment_rows.value %}
{% if rows != blank %}
  <h3>车型适配资料：请逐行核对全部条件</h3>
  <ul>
  {% for row in rows %}
    <li>
    {% if row.review_state.value == '资料已核准' %}
      <p><strong>{{ row.row_label.value | escape }}</strong></p>
      <p>{{ row.public_summary.value | escape | newline_to_br }}</p>
      <p>资料版本：{{ row.source_label.value | escape }}；复核日期：{{ row.reviewed_on.value | escape }}</p>
    {% else %}
      <p>此条资料需人工复核，不作为适配结论。</p>
    {% endif %}
    </li>
  {% endfor %}
  </ul>
{% else %}
  <p>本商品暂无可显示的适配资料，请提供车型、年份、发动机与市场，交人工核对。</p>
{% endif %}

公开说明、来源或日期为空时，即使状态文字正确也不应通过验收；代码没有替代这项人工完整性检查。页面另外保留“请逐行核对全部条件；资料外组合需人工确认”的提示，不给所有来访者显示无条件的“适用于您的车辆”。

用反例检查交付物

交付物应包含：原表到 F01/F02 的对照记录、商品关联记录、主题副本预览截图、验收结果与失败原因。以下是待执行的检查，不是已完成的测试。

若后来收到新版原表，先记录受影响的商品与行号，复核完整条件，再更新对应条目并重新检查所有使用位置。不能仅把来源版本号换新，却继续保留旧条件。

FAQ

存入适配元对象后，就能自动匹配车型吗？

不能。本流程提供逐行资料的录入与展示；车型选择器、条件查询、数据授权与匹配结果校验需要另外实现和验证，保存字段本身不完成这些工作。

已选入列表的 Draft 条目为什么不显示？

当定义启用了 Active-draft status，Draft 条目不能在 Liquid 中访问。先确认资料确已审核、可以公开，再决定是否改为 Active；不要为了让页面有内容就放行未核实行。