我们的 Shopify 退出策略：评估无头电商替代方案

Shopify 确实擅长它所针对的业务：结账转化率高，应用生态丰富，运行可靠。对于希望销售产品而不想自建基础设施的商家，它的价值很有说服力。在解释我们为何关闭 Shopify 商店之前，有必要先说明这一点：这个决定并不是因为 Shopify 总体能力不足，而是它不适合我们逐渐积累的特定运营需求。

多数关于“退出 Shopify”的讨论集中在交易费、主题限制或定制网店前端的愿望上。这些理由确实存在，却不是最关键的。更根本的问题是，Shopify 针对特定类型的商家做了优化：销量大、产品目录标准化、直接面向消费者。需求一旦偏离这一模式，平台约束就会成为阻力。

Shopify 的优势

结账是 Shopify 最具竞争力的部分。多年在数百万家商店中的优化，形成了能促进转化、妥善处理边缘情况、支持不同市场支付方式的结账流程，无需商家自行开发集成。从零构建同等能力需要数月，后续维护开销也很大。

订单管理、履约、退货和客服工具等运营功能同样成熟。后台界面有明确的设计取向，但体现了规模化电商运营的实际经验。需要让非技术人员上手管理订单的团队，会发现 Shopify 的用户体验明显优于目前可用的任何无头替代方案。

应用生态虽然常被批评存在隐性成本，却能解决实际问题。评价平台、订阅计费、会员积分计划、高级分析等集成之所以能正常运行，是因为 Shopify 标准化了第三方应用依赖的 webhook、数据模型和身份验证。在无头架构下，每项集成都必须定制开发，或向未必原生支持所选平台的供应商采购。

成为障碍的平台约束

最初的阻力来自国际化（i18n）限制。Shopify 的多语言支持虽比早期大幅改善，仍将非英语市场视为次要需求。在 Shopify 后台管理十几种语言的内容，操作上的困难会随产品目录规模扩大而加剧。翻译应用有所帮助，却增加了成本和同步复杂性，而原生方案本可消除这些问题。

随着时间推移，数据所有权成为更根本的问题。所有重要运营数据，包括订单历史、客户记录和产品目录，都在 Shopify 的数据库中，只能通过 Shopify 控制的 API 访问。API 速率限制、数据保留政策和导出格式由 Shopify 决定，而非商家决定。对需要分析自身运营数据的团队而言，这是结构性约束，无法通过配置解决。

第三个约束是定价模型的复杂性。变体众多的产品、按客户群体定制的价格，以及面向企业客户的报价流程，都会与 Shopify 的变体限制（每个产品原为 100 个，直到 Shopify 于 2025 年 10 月将上限提高至 2,048 个）和定价结构发生冲突，需要越来越复杂的变通方案。由此产生的 Liquid 模板复杂性成为维护负担，难以应对产品目录的持续增长。

评估：Medusa v2、Saleor 和 Commerce.js

我们按四项标准评估：数据所有权，即完全控制数据库、没有供应商施加的 API 限制；国际化深度，即原生支持多币种、多语言和区域定价；开发者体验，包括文档质量、TypeScript 支持和本地开发流程；以及运营成熟度，包括生产部署、已知故障模式和社区规模。

Medusa v2 的开发者体验最好。v2 重写显著改善了原有架构：模块系统设计良好，TypeScript 类型完整，本地开发流程快速。文档也大幅改善，体现了团队对开发者体验的重视。限制在于运营成熟度：v2 相对较新（Medusa 2.0 于 2024 年 10 月发布），生产部署案例比成熟平台更少，场景也不够多样。迁移到 Medusa 的团队，确实需要承担早期采用者的角色。

Saleor 是三者中经生产实践验证最充分的方案，生产部署基础更大，GraphQL API 设计良好。其多渠道架构用“渠道”区分不同市场、网店前端和客户群，能比其他方案更自然地处理促使我们离开 Shopify 的定价与产品目录复杂性。三者中它的运营成熟度最高，代价是学习曲线较陡，而且以 GraphQL 为核心的 API 需要先投入工具建设，才能高效使用。

Commerce.js 定位不同：它是一套无头 API，而非完整电商平台，旨在与其他服务组合，而不是单独提供全部能力。对于工程资源充足、希望精细控制每个组件的团队，它是合适的选择。但如果目标是摆脱 Shopify 的运营开销，又不想换一种形式承担同等工程开销，它可能并不适合。由于它是托管 API，也无法让您完全控制数据库，而这正是我们的第一项标准。此外，截至 2026 年 10 月，Commerce.js 背后的公司 Chec 已将其 GitHub 组织归档（归档于 2024 年 10 月），因此在考虑采用之前，请先核实该服务的当前状态。

迁移路径

平台迁移最容易被低估的成本是数据迁移，而非代码迁移。将产品目录、客户记录和订单历史从 Shopify 移到新平台，需要定制提取脚本、按目标数据模式转换，以及谨慎处理边缘情况，例如超过 100 个变体的产品、地址历史复杂的客户和部分履约订单。这些记录占比不高，却会消耗大量迁移工程时间。

运营过渡期间，需要让订单同时经过两套系统，以验证迁移结果，因此必须认真规划，避免重复履约或重复联系客户。多数迁移在此阶段遇到计划中未预料的问题，因为关键边缘情况取决于商家自身的产品目录和订单历史，而不是电商业务的一般规律。

我们从这次评估及其他团队的类似经历中得到的结论是：迁移规划的质量，比平台选择本身更重要。Medusa 和 Saleor 都能支撑生产环境的电商运营，Commerce.js 在我们评估时也具备这一能力。无头迁移成功的团队，会在迁移开始前理解数据模型的差异，而不是迁移过程中才研究。