Shopify 原生功能与 App 怎么分工：先判断需求属于主题、数据还是服务

判断 Shopify 功能该留在主题还是交给 App，关键不是“原生一定省钱”或“App 一定专业”，而是先分清这个需求到底是页面展示、商品数据、交易服务还是跨系统流程。能由主题、区块和商品数据稳定表达的内容，不必为了一个简单效果再增加前台依赖；需要外部计算、账户、同步、合规或持续运营的服务，也不应硬写进主题。

先把需求放进四个盒子

很多功能讨论会从“有没有 App”开始，结果把不同性质的问题混在一起。更有效的起点是先问：访客看见的是什么，商家需要改什么，数据来自哪里，功能失效时谁负责恢复。通常可以先分成四类。

• 需求类型：固定或可配置的页面展示；更常见的承载方式：主题 section、block、settings；典型例子：品牌介绍、卖点、FAQ 样式、落地页版式；先问的边界：运营能否在主题编辑器安全修改？
• 需求类型：随商品或页面变化的数据；更常见的承载方式：商品字段、metafield、metaobject 与主题渲染；典型例子：尺码表、材质、护理说明、参数、品牌故事；先问的边界：数据是否要随着当前商品自动变化？
• 需求类型：需要外部系统或账户的服务；更常见的承载方式：App 或服务端集成；典型例子：订阅、评论、忠诚度、税务、物流、客服；先问的边界：是否需要供应商持续提供后台、规则或同步？
• 需求类型：复杂的业务判断和交易流程；更常见的承载方式：App、定制应用或系统集成；典型例子：多条件赠品、会员权益、库存分配、B2B 定价；先问的边界：是否涉及跨页面状态、订单或外部数据？

这个分类不是技术炫耀。它能阻止一个常见误判：把“产品页需要显示护理说明”直接等同于“必须装一个说明 App”。如果说明来自每个商品自身的数据，主题可以读取并在正确位置展示；若它还涉及第三方认证查询、复杂规则和后台编辑权限，才需要进一步评估服务层。

主题原生能力适合承担什么

Shopify 主题的 section、block、模板和设置，本质上是给商家可控地组织页面内容和外观。Shopify 的主题编辑器说明也明确，开发者可以通过模块化的 section、block 与 settings 让商家在后台完成可预期的调整。主题编辑器文档和主题架构说明都把这些能力作为主题可维护性的基础。

更适合主题原生处理的，通常有三个特征：

1. 需求的核心是“怎么展示”，而不是“从外部系统取回什么”。
2. 内容变化可由主题设置或商品数据驱动，不需要供应商账号去计算规则。
3. 功能在断开某个第三方服务后，仍应保留最基础的阅读和购买路径。

例如，首页的品牌卖点、一个可重复使用的内容区块、产品页的配送说明位置、可由商品字段驱动的规格列表，通常优先考虑主题结构和数据模型。Shopify 对区块的建议也强调，区块可复用、可增删和重排；对产品特定信息，则可以评估标准 metafield 和动态数据源。Blocks 最佳实践给出的尺码表和护理说明就是类似思路。

这不代表主题应该承担所有功能。主题能展示一个“订阅说明”，不等于它能安全管理订阅合同、扣款规则或客户账户；主题能显示推荐内容，不等于它应自己维护复杂的推荐模型。

App 的价值在于服务，不在于多一个按钮

App 更适合承载主题之外的持续服务。比如需要第三方系统同步、订阅管理、真实评价收集、客服会话、仓储/履约连接、支付或税务规则时，价值不只在页面上多出一个组件，而在它背后有独立的账户、权限、任务、数据与维护责任。

这类需求如果硬塞进主题，短期可能看似省掉月费，长期却会把账号、订单状态、数据同步和错误处理分散到难以升级的 Liquid 与 JavaScript 里。真正要比较的不是“主题定制一次多少钱，App 每月多少钱”，而是以下三种成本：

• 比较项：规则变化；做进主题时要承担：开发者要改代码并回归测试；采用 App 时要承担：供应商升级，但商家要评估版本和权限
• 比较项：外部数据；做进主题时要承担：自建接口、鉴权、失败处理与监控；采用 App 时要承担：依赖供应商接口和服务稳定性
• 比较项：页面性能；做进主题时要承担：可以精确控制加载，但也要维护实现；采用 App 时要承担：需要检查脚本、App block 与加载范围
• 比较项：退出路径；做进主题时要承担：代码和数据归属需预先设计；采用 App 时要承担：要确认卸载后数据、页面和替代方案

App 不等于不可控。采用支持 App block 或 App embed 的接入方式，商家通常能在主题编辑器中管理位置和启停；直接修改主题代码的集成则需要留下更完整的变更记录。选 App 时要同时问它如何接入、在哪些页面加载、卸载后会怎样，而不只看功能截图。

一个购买路径里的具体判断

假设一个护肤品牌希望改产品页，提出四个要求：显示不同肤质的使用说明；收集评价；根据订阅周期给优惠；在购物车里按地区提示配送时效。它们不该由同一个“万能 App”一口吞掉。

- 使用说明如果随产品和变体变化，可先用产品数据与主题区块展示，让内容团队按产品维护。 - 评价需要用户提交、审核、展示和可能的第三方信任机制，更接近独立服务，应评估评价 App 的数据迁移和加载方式。 - 订阅牵涉计划、客户授权、订单与支付状态，应采用有明确订阅能力和责任边界的方案，不应只在主题里改一个价格文案。 - 地区配送提示可能只是静态解释，也可能需要读取真实库存、地址和承运商规则。前者可留在主题，后者需要把数据来源和失败状态说清。

把四个需求拆开后，功能不一定更多，页面却更清楚：主题负责稳定展示和基本体验，数据模型负责内容变化，App 或服务负责需要长期运行的业务逻辑。

在安装或开发前问五个问题

无论准备装 App 还是改主题，先写下这五个问题：

1. 这个功能最少要在哪些页面出现？
2. 它依赖的内容和规则由谁维护，多久会变一次？
3. 它是否读取、写入或影响订单、客户、支付、库存等核心数据？
4. 断开服务、卸载 App 或升级主题后，访客会看到什么，运营还保留什么数据？
5. 是否可以先用一个代表性商品、一种优惠和一条真实购买路径验证，再全站铺开？

若答案主要是“某个区块怎么排、文案怎么换、不同商品显示什么”，优先从主题和数据模型开始。若答案涉及“谁来计算、谁来同步、谁来承担异常和持续更新”，再进入 App 或定制服务评估。这个顺序能减少功能叠加，也能避免把一个服务 App 当成解决所有内容和页面问题的捷径。

李李出海在 Shopify 项目中会先把需求拆成展示、数据与服务三层，再决定主题改造和 App 接入。这不是追求少装 App，而是让每个依赖都有明确的业务理由、页面范围和退出路径。

本周可以挑一个准备新增的功能，按上面的四类写出数据来源、出现页面和失效后的影响。只要这三项仍写不清，就先不要安装或开发；需求边界没有确定时，任何方案都会在后续升级里变成隐性成本。