直接答案：二开应扩展 OS 2.0 架构，而不是制造不可升级的主题分支
Shopify 主题二次开发的正确目标是：在不破坏运营编辑能力、性能和升级路径的前提下，用 Liquid、JSON 模板、sections、blocks、snippets、assets 与 app blocks 实现经过验证的业务需求。 Shopify 主题没有 WordPress 式“父主题/子主题继承”，也不存在用根目录 theme.json 继承另一套主题的官方机制。当前官方结构使用 layout、templates、sections、blocks、snippets、assets、config 和 locales 等目录；配置数据位于 config，JSON 模板位于 templates。
Shopify 的主题架构文档说明，layout 提供页面基础，template 决定页面类型内容，sections 和 blocks 提供可复用、可在编辑器调整的模块。只有 layout/theme.liquid 是主题上传的最低必需文件。任何把 theme.json、父子主题或 PHP 模板层级写成 Shopify 标准的旧教程，都应删除或重写。
| 需求 | 优先实现层 | 原因 | 不宜做法 |
|---|---|---|---|
| 页面布局可编辑 | JSON template + section | 运营可添加、排序和配置模块 | 把整页 HTML 写死在一个 Liquid 文件 |
| 重复的小型界面逻辑 | snippet 或 theme block | 复用、参数化、职责清楚 | 复制到多个 section 后分别维护 |
| 应用功能 | app block / app embed | 便于应用安装、卸载和升级 | 让应用永久改写主题核心文件 |
| 全局视觉与选项 | section/theme settings + CSS 变量 | 可控配置与设计系统一致 | 每处独立 hard-code 颜色和间距 |
| 复杂业务流程 | 应用、Function 或后端集成 | 主题不是安全业务后端 | 在 Liquid 中模拟库存、权限或密钥逻辑 |
第一步：先判断是否真的需要二开
先写需求、用户问题和验收条件，再选择实现层。字体、颜色、区块顺序、简单内容模块常可在主题编辑器或现有 section 完成；评论、订阅、捆绑、筛选等能力可能已有可靠 app block；只有标准能力无法满足且价值明确时，才新增定制代码。二开不等于把设计稿每个像素固定下来，应该保留商品、集合、语言、市场和运营内容的变化空间。
评估前记录当前主题名称与版本、来源与许可证、已改代码、应用嵌入、模板分配、核心页面性能和升级历史。Shopify 建议在定制前复制主题作为备份；这只是可恢复副本，不是子主题继承。需要系统评估时，可参考 WESWOO 的Shopify 服务与项目案例整理范围，不从案例推断固定转化结果。
第二步：按当前主题目录分配职责
layout/theme.liquid 放所有页面共享的文档骨架、head 输出、全局 section group 与必要资源入口，不应堆进每个页面的业务组件。templates/*.json 保存页面由哪些 sections 构成及其配置；Shopify 的 JSON 模板说明指出，商家可以在编辑器中添加、移除和排序这些 section。一个 JSON 模板最多渲染 25 个 sections，每个 section 最多 50 个 blocks，架构时不应靠无限嵌套解决所有需求。
sections/*.liquid 负责有 schema 的可配置模块，blocks/*.liquid 可提供主题级可复用 blocks，snippets/*.liquid 存放较小、不可由运营直接配置的复用片段。assets 存放 CSS、JavaScript 和静态资源，locales 存放主题界面翻译，config/settings_schema.json 定义主题级设置，config/settings_data.json 保存实际设置值。自定义数据优先评估 metafields 和 metaobjects，不要把每个商品差异硬编码进模板。
Section schema 的设置要有明确标签、默认值和边界。允许商家选择图片、文本、商品、集合、颜色或间距时，要处理空值和合理降级；重复 blocks 要限制数量并提供 preset。界面文本用 locale key，商品和营销内容由相应内容对象管理，避免翻译工具无法发现写死文本。
第三步：Liquid 只做展示层，JavaScript 按需增强
Liquid 在服务端生成 HTML，适合输出商品、集合、导航、metafield 和主题设置。Snippet 接收明确参数，不依赖难以追踪的全局副作用；昂贵循环先限制集合范围，避免在多层循环里重复筛选整个商品集。HTML 应语义化，按钮和链接用途清楚，图片包含尺寸与响应式来源，表单具有 label、错误提示和键盘焦点。
JavaScript 应增强已有 HTML，而不是让基本商品信息或导航必须等客户端脚本才出现。按 section 或功能拆分并延迟非关键代码，避免每个页面加载所有 slider、弹窗和追踪库。Shopify 的主题开发最佳实践建议优先使用现代浏览器原生能力并尽量减少 JavaScript。性能验收要在真实商品、应用、移动设备和网络下进行，而不只测空白开发店。
如性能已是主要问题，可先运行Shopify 速度优化指南的基线与瓶颈排查。二开新增的每个媒体、字体、应用和交互都应有性能预算，不能在最后一天才“压缩一下”。
第四步：使用 CLI、版本控制和可回滚发布
Shopify CLI 支持 development theme、本地预览、热更新、Theme Check、push 与 publish。官方 CLI 说明指出 development theme 是临时且隐藏的，可使用商店数据测试；长效评审链接应推送到未发布主题。代码放入 Git，分支与任务或发布对应，提交信息说明需求和影响；settings_data.json 等环境数据要谨慎处理，避免覆盖运营刚做的配置。
建议流程是：从明确的基线主题建立仓库；开发分支运行 Theme Check 和格式检查；在 development theme 开发；推送到未发布主题完成商品、语言、应用、移动端与可访问性验收；记录目标主题 ID 和备份；由授权人员发布；发布后执行最小购买路径；异常时切回已验证主题。不要在正式主题代码编辑器里做无法追踪的大改。
应用优先使用 Theme App Extension 的 app block 或 app embed，减少直接修改。卸载、关闭或更新应用时，检查是否仍有残留 snippet、脚本和设置。第三方脚本必须有业务所有者、加载范围和同意要求。
第五步：把主题升级纳入架构，而不是上线后再处理
主题商店的新版本可以添加到草稿主题；Shopify 的主题更新说明列出了可复制的编辑器配置和代码合并边界。大量修改供应商核心文件会增加冲突和人工迁移成本。官方没有子主题自动继承，因此团队要用 Git 历史、模块化修改、变更记录和回归测试维持升级能力。
每次更新应先阅读 release notes，在草稿主题合并，比较模板、settings、sections、应用扩展和自定义代码，再测试首页、集合、搜索、商品变体、加购、抽屉购物车、账户、语言/币种、结账跳转和分析。升级不是“新版本覆盖旧版本”，而是一次受控迁移。
主题二开验收清单
- [ ] 需求不能仅靠编辑器或成熟 app block 更低风险实现；
- [ ] 未使用
theme.json或父子主题概念解释 Shopify 架构； - [ ] JSON templates、sections、blocks 与 snippets 职责清楚；
- [ ] 运营可编辑内容、空状态和翻译均通过验收；
- [ ] JavaScript 按需加载，移动端性能与可访问性实测；
- [ ] Git、Theme Check、开发/草稿主题和回滚路径已建立；
- [ ] 应用、分析、同意、多市场与购买路径完成回归测试；
- [ ] 供应商主题更新有负责人和定期复核计划。
常见问题
Shopify 有像 WordPress 一样的子主题吗？
没有官方父子主题继承机制。复制主题可以备份，但不会自动继承上游更新。版本管理依赖 Git、模块化开发和受控升级。
Shopify 主题根目录有 theme.json 吗？
没有这种官方根配置模型。主题使用标准目录，配置文件位于 config，JSON 页面模板位于 templates。
Liquid 可以实现任何业务逻辑吗？
不应这样使用。Liquid 是展示模板语言。需要安全密钥、后台权限、复杂持久化或订单侧逻辑时，应使用应用、Shopify Functions 或合适后端能力。
修改主题后还能获得供应商更新吗？
可能，但定制代码越分散、越深入核心文件，冲突和迁移成本越高。应在草稿主题评估更新，用 Git 对比并完整回归。
二开一定比购买新主题好吗？
不一定。若基础架构、可访问性或性能已不适合目标，迁移到更合适的主题可能比长期修补更经济；决策应比较需求、迁移和维护总成本。