Shopify 主题的 section、block 和 JSON 模板是什么关系？可自定义页面怎么搭

很多品牌方第一次接触 Shopify 主题定制时，会遇到一个困惑：为什么首页可以在主题编辑器里随意增删模块，某些页面的某个区域却怎么都改不动？答案在主题的结构设计里。Online Store 2.0 之后，Shopify 主题的可编辑页面由三层组成：JSON 模板决定一个页面放哪些 section，section 是可复用的内容模块，block 是 section 内部可以增删排序的更小单元。

理解这三层，品牌方能更准确地提需求，技术人员能判断哪些东西应该开放给运营、哪些应该锁死在代码里。下面按官方文档的当前说法逐层说明，并以 Shopify 官方主题的做法为例。

一、JSON 模板：页面是一份 section 清单

在 Online Store 2.0 主题里，商品页、集合页、普通页面等模板通常是 templates 目录下的 JSON 文件，而不是一段 Liquid 代码。按 JSON 模板文档，这个文件主要包含三部分：sections 对象记录每个 section 的类型和设置值，order 数组决定渲染顺序，另外可以指定使用哪个 layout，以及用 wrapper 给所有 section 外面包一层 div、main 之类的标签。

商家在主题编辑器里做的操作，本质上就是在改这份 JSON：添加 section 是往 sections 里加一条，拖动顺序是改 order，调整文字和图片是改 settings。这也是为什么同一个主题可以给不同商品配不同的页面布局。

• 一个 JSON 模板最多渲染 25 个 section，每个 section 最多 50 个 block；
• 一个主题最多可以有 1000 个 JSON 模板；
• 可以建备用模板，例如 product.alternate.json，在后台给特定商品指定使用；
• section 数据不能跨 JSON 模板共享，同一个 section 放在两个模板里，是两份独立的设置；
• 礼品卡等少数模板类型不能使用 JSON 格式，要继续用 Liquid 模板。

「数据不共享」这一点经常被忽略。例如商品页有三个备用模板，每个都放了同一个「售后说明」section，改说明时就要改三次。对需要跨页面统一维护的内容，更合适的做法是放进元字段或元对象，由 section 通过 product 等 Liquid 对象的 metafields 属性读取，而不是在每个模板里各填一遍。

二、section：可复用的内容模块和它的 schema

section 是 sections 目录下的 Liquid 文件，每个文件末尾用 schema 标签声明一段 JSON 配置。按 section schema 文档，常用的属性包括：

• name：在编辑器里显示的名称，支持多语言；
• tag 与 class：section 外层包裹元素的标签和类名；
• settings：商家可以调整的设置项，例如文本、图片、颜色、商品选择器；
• blocks 与 max_blocks：允许哪些 block，以及数量上限，平台上限是 50；
• presets：让 section 出现在编辑器「添加分区」列表里的预设配置；
• default：静态渲染的 section 使用的默认配置；
• limit：限制同一模板里这个 section 只能出现 1 次或 2 次；
• enabled_on 与 disabled_on：限制 section 能用在哪些模板或 section group 里，两者只能用其一。

presets 和 default 的区别

这是新手最容易混的地方。presets 是给 JSON 模板用的：定义了 presets，商家才能在编辑器里通过「添加分区」把这个 section 加进页面，一个 section 可以有多个 preset，对应不同的初始布局。default 是给静态渲染用的：当开发者在 Liquid 代码里直接用 section 标签把某个 section 写死在页面上时，用 default 提供初始设置。官方文档明确说明，一个 section 只能用 presets 或 default 其中之一，带 presets 的 section 不应该被静态渲染。

静态 section 与 JSON 模板里的 section

section 文档列出了三种渲染方式：放进 JSON 模板、放进 section group，或者用 section 标签静态渲染。静态渲染的 section 位置固定，商家不能删除或移动，而且同一个静态 section 在所有引用它的地方共享同一份设置。官方目前的建议是尽量用 JSON 模板，少用静态渲染，以获得更好的自定义能力和性能。静态渲染更适合那些「必须出现、位置不能动」的少数场景。

三、block：section 里的最小可编辑单元

block 让 section 内部也能自定义。以商品详情为例，标题、价格、规格选择器、加购按钮、描述都可以做成独立的 block，商家可以调整顺序、隐藏某项，或者再加一段自定义文字。按 blocks 文档，当前有三类 block：

1. section block：定义在 section 自己的 schema 里，只能在这个 section 中使用，只有一层，不能嵌套；
2. theme block：放在主题的 blocks 目录下，是独立的 Liquid 文件，可以被多个 section 复用，还可以互相嵌套，一个主题最多 300 个 theme block；
3. app block：由已安装的应用提供，section 在 schema 里声明支持 @app 类型后，商家就能把应用的组件放进来。

theme block 还支持「静态 block」：由开发者固定在 section 的某个位置上，商家可以隐藏但不能删除。这适合商品页里那些必须存在、但允许调样式的元素。需要注意的是，一个 section 要么使用自己定义的 section block，要么声明接收 theme block，两种不能在同一个 section 里混用。

四、section groups：头部、页脚也能自由编辑

早期主题的头部和页脚通常是静态 section，商家只能改设置，不能在头部上方加一条公告栏、在页脚前插一块订阅模块。section groups 解决了这个问题：它是一种特殊的 JSON 文件，类型可以是 header、footer、aside 或自定义类型，在 layout 里用 sections 标签渲染。商家在编辑器里可以往 group 里增删、排序 section，和编辑普通页面一样。section group 与 JSON 模板的数量上限相同：最多 25 个 section，每个 section 最多 50 个 block。

对需要按市场做差异化的外贸店铺，section groups 还有一个实用价值：公告栏、页脚联系方式这类区域可以交给运营按需调整，而不必每次找开发者改代码。

五、以官方主题为例：结构是怎么组织的

Dawn 是 Shopify 第一个源码公开、内置 Online Store 2.0 特性的参考主题，它的主商品 section 是「section 里放 section block，并接收 app block」的典型写法。之后 Shopify 推出的 Horizon 被官方称为新一代第一方主题的旗舰，采用了 theme block，商品信息、卡片等结构可以由可复用、可嵌套的 block 组合而成。

两者对比能看出官方的方向：从「每个 section 自带一套 block」走向「一套 theme block 在多个 section 间复用」。对开发者来说，读 Horizon 的 blocks 目录，是理解 theme block 用法最直接的方式。需要提醒的是，按 Theme Store 当前要求，新提交上架的主题不能基于 Dawn 或 Horizon 派生；如果只是给自家店铺做定制，以官方主题为基础二次开发仍然是常见做法。

六、开发时的取舍：开放多少给商家

section 和 block 让页面几乎可以无限组合，但开放得越多，出错的空间也越大。定制主题时，我们通常按下面几条来判断：

• 品牌一致性优先的元素少开放：品牌色、字体、按钮样式放在主题全局设置里统一管理，不在每个 section 里重复提供颜色选项；
• 运营高频修改的内容多开放：首页横幅、活动专区、公告栏、商品页卖点，做成 section 或 block，并配好 presets；
• 结构性元素用静态 block 或固定位置：价格、加购按钮这类影响下单的元素，可以允许隐藏或调样式，但不要让它们能被误删；
• 跨页面共享的数据不要写在 section 设置里：规格参数、尺码表、售后政策放元字段或元对象，避免多个模板各维护一份；
• 设置项宁少勿滥：每加一个开关都要考虑编辑器的可理解性，以及它对性能和可访问性的影响；
• 预留 app block 位置：在商品页、购物车等应用常用的 section 里声明支持 @app，将来接入评价、订阅类应用时不需要改代码。

好的主题结构，是让运营能自己改的都能改，改不得的改不了。

这些取舍和选择建站平台本身的思路一脉相承：Shopify 的编辑器能力很强，但它仍然是一个受平台约束的 CMS。在 Shopify、WooCommerce 与自研的选型对比里我们提到过，平台型方案的优势在于有人帮你维护底层，代价是结构要顺着平台的设计走。

大乐网络在做外贸独立站时，会在需求阶段先和运营团队一起列出「哪些内容要自己改、多频繁改」，再据此设计 section 和 block 的颗粒度，而不是先堆出一个什么都能改的主题。