先判断问题出现在哪里
在过去，如果你想在产品 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 检查结果。技术修改还要保留测试记录和回滚版本。
哪些情况不建议马上修改？
数据量太少、追踪没有配置、问题还没有复现，或者正在进行大型主题更新时，不建议一次性重做。先把问题拆开，确认影响范围后再改。