先判断问题出现在哪里
在过去,如果你想在产品 A 的页面显示“材质:纯棉”,在产品 B 的页面显示“材质:真丝”,你只能硬编码,或者建两个不同的页面模板。这极其低效。

核心逻辑是:结构化数据的动态绑定。
Metafields(元字段)允许商家在 Shopify 后台为产品、客户、订单添加自定义的数据字段(如文本、图片、甚至 JSON)。而动态数据源(Dynamic Sources)则允许你在主题编辑器中,将一个普通的文本 Block,直接绑定到某个 Metafield 上。实现“一个模板,千人千面”的数据渲染。
实战步骤
步骤 1:在后台创建 Metafields 定义
操作路径:Shopify后台 -> 设置 -> 自定义数据 -> 产品
- 点击“添加定义”。
- 名称:例如“洗涤说明”。
-
命名空间和键 (Namespace and key):这是代码调用的核心,例如
custom.wash_care。 - 选择类型:选择“单行文本”或“多行文本”。
- 保存后,进入任何一个产品编辑页,滚动到底部,你就能看到“洗涤说明”的输入框了。
步骤 2:在 Liquid 中直接渲染 Metafields
操作路径:在产品页的 section 或 snippet 中编写代码
- 如果你想通过代码强制渲染(不让商家在后台控制):
{% if product.metafields.custom.wash_care != blank %} <div class="wash-care-info"> <h4>洗涤说明</h4> <p>{{ product.metafields.custom.wash_care }}</p> </div> {% endif %} -
判空极其重要:必须使用
!= blank检查该产品是否填写了这个元字段,否则会渲染出一个空荡荡的<div>标签。
步骤 3:支持主题编辑器的“动态数据源”绑定
操作路径:无需写特殊代码,使用标准的 Schema 即可
- 只要你在 Section 的 Schema 中定义了一个标准的
text或image_picker类型的 setting。 - 商家在主题编辑器中点击这个文本框时,右上角会出现一个“连接动态源(Connect dynamic source)”的图标(三个堆叠的圆圈)。
- 点击图标,商家就可以直接选择刚才创建的“洗涤说明”Metafield。
- 优势:这种方式将数据绑定的权力交给了商家,代码极其干净,复用性极高。
常见误区与处理方法
误区一:使用了错误的 Metafield 数据类型导致前端渲染报错
规避方法:Metafields 支持极其丰富的数据类型(如颜色、日期、重量、甚至产品引用)。如果你在后台创建了一个“产品引用(Product Reference)”类型的元字段,但在前端 Liquid 里直接写 {{ product.metafields.custom.related_item }},页面会直接报错或输出 gid://shopify/Product/123456 这种毫无意义的内部 ID。必须根据数据类型调用对应的属性或过滤器。 对于产品引用,必须先获取对象:{% assign related_product = product.metafields.custom.related_item.value %},然后再输出 {{ related_product.title }}。
误区二:滥用 Metafields 存储海量的 JSON 结构化数据
规避方法:有些开发者发现 Metafields 支持 JSON 类型,于是把整个页面的排版数据、复杂的嵌套数组全塞进一个 Metafield 里,然后在前端用 Liquid 的 for 循环去解析渲染。这会导致 Liquid 渲染极其缓慢,且商家在后台根本无法直观地修改这些 JSON 字符串。Metafields 应该只用于存储纯粹的、扁平化的业务数据(如参数、短文本、单张图片)。 复杂的页面排版和嵌套结构,必须回归到 OS 2.0 的 JSON Templates 和 Blocks 机制中去解决。
误区三:没有处理 Metafields 列表 (List) 类型的循环逻辑
规避方法:在后台创建元字段时,你可以勾选“接受值列表(List of values)”,比如为一个产品添加多个“适用场景”标签。如果你在前端直接输出这个列表变量,它会把所有标签连在一起变成一坨乱码。对于列表类型的 Metafields,必须使用 for 循环进行遍历渲染。
{% if product.metafields.custom.usage_scenarios.value != blank %}
<ul class="tags">
{% for scenario in product.metafields.custom.usage_scenarios.value %}
<li>{{ scenario }}</li>
{% endfor %}
</ul>
{% endif %}
注意,必须加上 .value 才能获取到真正的数组对象进行遍历。

FAQ
动态数据源应该先检查什么?
先在测试主题或测试页面中操作,并保留修改前版本和验证记录。不要同时改很多位置,先记录当前页面和数据,再处理最明确的问题。
需要马上安装新的 Shopify App 吗?
不一定。先判断主题现有功能、后台字段和少量代码能否解决。只有需要持续同步数据或复杂自动化时,再评估 App 的费用、脚本负担和卸载影响。
修改后怎么验证是否有效?
记录修改日期、页面 URL 和改动内容,再用实际页面、移动端、Google Search Console、Bing Webmaster Tools 或 GA4 检查结果。技术修改还要保留测试记录和回滚版本。
哪些情况不建议马上修改?
数据量太少、追踪没有配置、问题还没有复现,或者正在进行大型主题更新时,不建议一次性重做。先把问题拆开,确认影响范围后再改。