先判断问题出现在哪里
在旧版（Vintage）主题时代，只有首页（index.liquid）支持自由拖拽区块（Sections）。产品页、博客页的排版是被写死在代码里的，商家想加个图文介绍，只能求助程序员。
核心逻辑是：数据与视图的彻底解耦。
Online Store 2.0（OS 2.0）是一场革命。它将所有页面的模板从 .liquid 变成了 .json。JSON 文件只负责记录“这个页面有哪些 Section，它们的顺序是什么，商家填了什么数据”。而真正的 HTML 渲染逻辑，全部下放到了独立的 Section 文件中。这就实现了 Sections Everywhere（随处可用区块），让商家在任何页面都能像搭积木一样自由排版。
实战步骤
核心机制 1：理解 JSON 模板的结构
操作路径：打开 templates/product.json
- 一个标准的 JSON 模板包含三个核心对象：
sections,order,wrapper。 -
sections：定义了页面上所有的区块实例。每个实例都有一个唯一的 ID（如 "main"），并指定了它使用的是哪个 Section 代码文件（type: "main-product"），以及商家在后台配置的数据（settings）。 -
order：一个数组，决定了这些 Sections 在页面上从上到下的渲染顺序（如["main", "recommendations", "reviews"]）。
核心机制 2：创建多套页面模板 (Multiple Templates)
操作路径：Shopify后台 -> 在线商店 -> 模板 -> 自定义 -> 顶部下拉菜单
- 在 OS 2.0 中，你可以为同一种页面类型创建无数个不同的排版。
- 例如，创建一个
product.vip.json。在这个模板里，你可以添加一个专属的“VIP 会员说明” Section。 - 然后在 Shopify 后台的产品管理页面，将特定产品的“模板后缀（Theme template）”指定为
vip。这样，普通产品和 VIP 产品就能展示完全不同的页面结构。
核心机制 3：Section 的独立渲染 (Section Rendering API)
操作路径：前端 Ajax 请求
- OS 2.0 允许你通过 API 单独请求某个 Section 的 HTML，而不需要刷新整个页面。
- 例如，在实现“点击加载更多”时，你可以向 Shopify 发送请求：
/collections/all?section_id=product-grid&page=2。 - Shopify 服务器只会返回
product-grid.liquid这个 Section 渲染后的 HTML 代码。前端拿到代码后直接插入 DOM，极大地提升了 Ajax 交互的性能。
常见误区与处理方法
误区一：在 JSON 模板中写注释或尾随逗号
规避方法：JSON 是一种极其严格的数据交换格式。很多前端习惯了在 JavaScript 的对象里写 // 这是一个注释，或者在数组的最后一个元素后面顺手加一个逗号 ,。在 Shopify 的 .json 模板文件中，绝对不允许出现任何注释和尾随逗号！ 一旦出现语法错误，整个页面在 Shopify 后台将直接白屏报错，商家无法进行任何操作。必须在 VS Code 中配置好 JSON 格式化工具（如 Prettier），保存时自动修复语法错误。
误区二：手动修改 JSON 模板导致数据丢失
规避方法：如前所述，templates/*.json 文件保存的是商家在可视化编辑器里辛辛苦苦填写的真实数据（比如一段精心撰写的品牌故事，或者上传的 Banner 图片链接）。作为开发者，你永远不应该在本地手动修改这些 JSON 文件中的 settings 数据，然后再 push 到线上。 你的修改会直接覆盖商家的心血。开发者只负责在 JSON 的 sections 中注册新的模块类型，具体的数据填充必须交由商家在后台完成。
误区三：遗留的 .liquid 模板阻碍了 Sections Everywhere
规避方法：如果你在升级一个老主题，或者从网上抄了一段旧代码，在 templates/ 目录下创建了一个 page.about.liquid。你会发现，当商家在后台编辑这个“关于我们”页面时，左侧的侧边栏根本没有“添加区块（Add Section）”的按钮！只要模板后缀是 .liquid，它就永远无法享受 OS 2.0 的自由拖拽特性。 必须将其转换为 page.about.json，并将原有的 HTML 代码提取到一个独立的 sections/main-page.liquid 中进行调用。
FAQ
OnlineStore2.0架构应该先检查什么？
先在测试主题或测试页面中操作，并保留修改前版本和验证记录。不要同时改很多位置，先记录当前页面和数据，再处理最明确的问题。
需要马上安装新的 Shopify App 吗？
不一定。先判断主题现有功能、后台字段和少量代码能否解决。只有需要持续同步数据或复杂自动化时，再评估 App 的费用、脚本负担和卸载影响。
修改后怎么验证是否有效？
记录修改日期、页面 URL 和改动内容，再用实际页面、移动端、Google Search Console、Bing Webmaster Tools 或 GA4 检查结果。技术修改还要保留测试记录和回滚版本。
哪些情况不建议马上修改？
数据量太少、追踪没有配置、问题还没有复现，或者正在进行大型主题更新时，不建议一次性重做。先把问题拆开，确认影响范围后再改。