自定义 section 的价值在于商家不用碰代码就能改内容。做不到这一点，它只是把硬编码换了个位置，还多出一个要长期维护的文件。判断要不要写，标准只有一个：同一类内容会不会反复出现，需不需要非技术人员自己调整。
一个最小可用的 section 长什么样
下面这个文件解决一类问题：产品页或首页需要一组可以增删的卖点。Liquid 部分只负责渲染，所有文案来自设置与 block。
结构、设置、默认值三部分（光算 · 示意图）
{% comment %} sections/value-props.liquid {% endcomment %}
<div class="value-props">
{% if section.settings.heading != blank %}
<h2>{{ section.settings.heading }}</h2>
{% endif %}
<ul>
{% for block in section.blocks %}
<li {{ block.shopify_attributes }}>
<h3>{{ block.settings.title }}</h3>
<p>{{ block.settings.text }}</p>
</li>
{% endfor %}
</ul>
</div>
{% schema %}
{
"name": "卖点列表",
"tag": "section",
"settings": [
{ "type": "text", "id": "heading", "label": "标题", "default": "为什么选我们" }
],
"blocks": [
{
"type": "item",
"name": "卖点",
"settings": [
{ "type": "text", "id": "title", "label": "小标题", "default": "48 小时内发出" },
{ "type": "richtext", "id": "text", "label": "说明" }
]
}
],
"presets": [
{ "name": "卖点列表", "blocks": [ { "type": "item" } ] }
]
}
{% endschema %}三段结构各管一件事：Liquid 部分渲染，schema 定义商家能改什么，presets 决定商家从编辑器添加这个 section 时的初始形态。schema 里的 tag 决定外层元素，settings 是模块级设置，blocks 定义可重复的条目类型。有一个原则值得写进代码规范：正文里出现的中文只应该出现在 label 和 default 里，页面上真正显示的文字必须来自设置、block 或元字段。
schema 标记是必需的，不是可选项。一个没有 schema 的 section 文件不会被识别成可配置模块；带 schema 之后，section 可以对所有模板可用，也可以用 enabled_on 或 disabled_on 把范围收窄到指定模板。默认值和区块定义都在这个标记里面，所以改 section 的能力范围，本质上是改 schema。
设置类型按商家最不容易填错的标准来选
单行文字用文本输入，段落用富文本，图片用图片选择器，跳转地址用链接类型，是否显示某一项用勾选框。选择依据是约束强度：能用开关表达的不要让商家填文字，能用选项表达的不要让商家手写字符串——手写的值一旦和代码里判断的条件不一致，功能就会静默失效，而且没人会发现，直到有人来问为什么这个开关没反应。
图片字段是出错最多的地方。用图片选择器时，商家没选图就直接渲染，页面上会留一个没有来源的图片标签，在手机端还可能撑出一个空框。图片、富文本这类可能为空的设置必须做非空判断，整段不渲染。标题同理，空标题会破坏页面标题层级，也让搜索引擎读到没有意义的文本。
默认值按装完就能上线来写
商家第一次添加这个 section 时看到的是 presets 生成的形态，presets 里没给默认值的字段就是空白，页面会显得塌陷。该填的都要填：一个真实场景的标题、一组能说明用途的卖点、富文本的初始结构。这不是为了好看，是因为大多数商家不会先去读你的说明文档，看到空白会认为 section 坏了，然后卸载或者随意乱填，最后你收到的反馈是自定义模块不好用。
默认值必须能直接上线看（光算 · 示意图）
预置 block 的数量也要想一下。预置三条，商家看到的是可以再添加的形态；预置八条，他得先删五条才能用。前者比后者省事，也更容易被继续使用。
复用的关键是别把某个品类写死
一个 section 解决一类内容，不解决某个具体页面。写死的品类文案、写死的联系方式、写死的价格说明，都会让这个 section 只能用一次。可复用的写法是把差异放进设置、block 和元字段：规格、使用场景、常见问题这类结构化内容交给元字段，section 只负责渲染与排版，这样同一个模块能落在不同产品上，看起来也确实是不同产品的内容。
命名同样影响复用。用统一前缀区分自定义 section 与主题自带文件，过几个月回来排查问题时，能一眼认出哪些是自己加的、哪些来自主题作者。如果某个自定义模块只服务一类模板，用 schema 里的启用范围限制住，比事后在编辑器里一个个删干净。
还有一层与复用相关的是设置的数量。一个 section 挂二十个设置项，商家改的时候要找半天；把同类设置分组、把低频设置收起来，能明显提高它被用起来的概率。设置项多并不等于灵活，多数时候它只是把设计决策推给了不擅长做这个决策的人。
性能预算要算在 section 里面
自定义 section 引入的图片、字体和脚本都计入页面成本，而且通常加在已有的第三方脚本之上。三件事按优先级排。首屏图片不能懒加载，用图片过滤器输出时给它加高优先级提示，相关文档说明了默认所有图片以低优先级被发现、首屏图需要显式提权的原理，同一份文档也提醒不要滥用，一页只给一张，用多了会干扰浏览器的优先级判断。首屏之外的部分做条件加载，位置判断要写成正向比较，因为在主题编辑器、静态 section 和接口返回的场景下位置取值是空的，写成等于判断会把这些场景一起送到懒加载分支。
图片留出尺寸、容器有固定比例，是避免布局偏移的基本做法。加载期间替换内容的做法（骨架屏、入场动画）要注意别把自己首屏的图藏起来，相关文档解释了为什么把内容放在透明度过渡和动画之后会推迟首屏渲染的计时，甚至让已经下载完成的图片不被计入。
字体和脚本是另一半。一个 section 自带一套字体文件、一个滑块库、一个动画库，成本会分散到很多页面上累积起来。能用主题已有资源就不要新引入一套，能延迟加载的脚本就不要放在渲染路径上。集合页的产品网格是最费成本的一类模块：卡片数量、图片尺寸、首屏几张提前加载，都该在这个 section 写的时候就定下来。同一个产品在集合页与产品页的路径处理不在这段代码里，但会跟着模板一起生效，集合内产品路径的排查属于同一层结构问题。首屏图的加载策略与性能基线怎么建立讲的是同一套判断方法，可以对照使用。
写完之后至少在三种状态下各看一次：主题编辑器里，也就是位置取值为空的场景；前台首屏；以及没有图片、没有文字的状态。第三种最容易发现问题，也最接近商家第一次添加这个 section 时的样子。
什么时候不该写自定义 section
三类情况不值得写。一次性内容：活动页只上线两周，用页面模板和现有模块拼出来就够，没必要多一份要维护的代码。主题已有设置能实现：多数主题的图文区、折叠问答、轮播都有对应模块，先翻一遍设置面板，比新写一个更快也更稳。需要复杂交互：筛选、按条件推荐、多步骤表单这类逻辑放在 section 里会变成一个长期维护的前端项目，要么用成熟应用，要么接受功能打折。
还有一类常被误判的是想让页面更好看。视觉调整属于样式层，改 assets 里的样式比新写一个 section 影响面更小，也不会给商家多出一个可能填错的设置项。
交付给商家时把三件事写清楚
自定义 section 上线之后，决定它能不能长期使用的往往是交接环节，代码质量只决定它会不会报错。交接至少写清三点：哪些设置可以放心改；哪些改之前要先确认，比如影响标题层级或结构化数据输出的字段；改坏了怎么恢复。第二点最容易被忽略，一个允许商家随意修改的标题字段，可能直接改掉页面的标题结构。
如果这个 section 会被人反复修改，就把限制写进 schema 的 label 里，而不是写在交接文档里。商家实际填写的地方，才是说明最该出现的地方。
边界：自定义 section 不受平台保证
自定义 section 是主题文件的一部分，没有平台层面的兼容承诺。主题作者更新主题时，你加的文件不会自动合并，也不会被升级流程照顾；改名、移动文件、升级主题之前，先确认它被哪些模板引用。反过来也一样，如果某个需求主题设置里已经能实现，写自定义 section 只多了一份维护成本。
容量上限是平台规则：一个 JSON 模板或分组最多渲染 25 个 section，每个 section 最多 50 个 block（section 文档）。想靠把一个模块拆成十个 section 来做精细控制，会先撞上限，也会让编辑器变得难用。section 能不能支持应用块，取决于它是否被 JSON 模板或分组引用，静态引入的 section 拿不到这项能力。
最后一句实话：自定义 section 解决的是展示与可维护性，解决不了内容质量。如果页面缺的是买家真正想看的参数和使用场景，换一个更漂亮的模块不会有任何变化。schema 上线之后就成了模板数据的依赖，之后再删掉某个设置 id，用到它的模板会保留旧值但不再渲染，表现出来是商家改了没反应；移除设置项要和移除模板里的引用一起做。光算不接 Shopify 主题与插件开发，我们做的是谷歌 SEO 与外贸独立站建设，技术 SEO 与内容结构的调整是我们动手的那一层，自定义开发通常由客户自己或主题作者完成。要先把这些文件的职责分清楚，可以看主题目录与模板的关系。