Shopify 替代品：选择需要更换的技术层

无头 Shopify 不是 Shopify 的替代方案。Shopify 文档指出无头商务将店面前端与后端分离,其 API"处理底层商务"。真正的问题是哪一层对你不适用:店面、商务运营还是平台本身。平台契合度的判断来自我的评估。功能声明来自厂商文档。

Shopify 替代方案:基于限制条件的直接答案

将方案与你能真正指出的限制条件匹配。

当前约束	测试路线	保留的内容	变化内容	验证工作流
主题加载缓慢、应用混乱、内容编辑不便	保持使用 Shopify 并修复主题、应用和内容工作流	产品目录、结账、订单、集成	主题代码、应用组合、编辑流程	主题审计、逐个应用评审、一次真实内容编辑从草稿到上线
店面需要非 Liquid 技术栈或集成 CMS	Headless Shopify。这是店面的变更：Shopify 保持为商务后端，不是替换平台	Shopify 中的目录、定价、结账、订单、支付	前端代码、托管、谁维护它	购物车、转向结账、客户登录、菜单和 metafields
应用无法修复的后端限制	BigCommerce，作为另一个托管商务后端	可能是店面，如果你构建 headless	目录、结账、订单、支付、管理员	变体导入、结账和支付，每个集成
你想拥有技术栈，或在 WordPress 上运行内容驱动的商店	WooCommerce	几乎没有超出你的目录数据	托管、更新、插件、管理员	结账、税务和运费规则、插件行为、备份
自定义商务工作流，由工程师拥有和维护	Medusa	前端，如果你已经是 headless	整个后端，由你构建和运行	一个端到端的自定义工作流，支付和履行提供商
目录和运营过于简单，感觉太复杂	Squarespace	你的产品数据，原则上	平台、管理员、结账、可能还有一些功能	变体、运费规则和订单流与你实际使用的情况

该表的两种解读很重要。如果你想要更简单的操作，更少的应用和更少的活动部分，实际可行的选择是整理现有的或将确实简单的目录迁移到更简单的平台。如果你需要自定义商务工作流，首先评估 Shopify 上的 headless。当业务系统、流程或客户体验无法通过 Shopify 的销售渠道、主题和应用来实现时，Shopify 建议团队考虑构建 headless。只有在后端是瓶颈时才替换后端。

问题是店面还是商务后端？

画一条线。一侧是展示层：模板、布局、编辑页面、菜单和商品展示块。另一侧是收款和发货的系统。

店铺前端：页面模板、内容、商品展示布局、前端行为。
后端：商品目录、定价、客户账户、结账、订单、付款、履单。

Hydrogen、Next.js 或任何自定义前端位于第一侧。保持这个区分清晰。Shopify 说明，前端从 Shopify 获取数据和商务功能：商品和集合、客户，加上购物车、结账和国际定价。它的帮助中心说得很明白：使用自定义店铺时，你用自己的店铺前端替换在线商店渠道，将其连接到 Shopify 作为后端，客户仍使用 Shopify Checkout 结账。你没有离开 Shopify。你只是改变了谁来搭建店铺窗口。

这带来成本。Shopify 指出，无头店铺的搭建和运营成本高于主题，商家需要开发人员在上线后维护。某些数据还需要令牌：商品标签、元字段、菜单和客户都在店铺 API 身份验证之后。API 是版本化的，每年发布四次，引入你使用主题时没有的维护节奏。

如果前端/后端边界是你当前的问题，无头电商开发页面有详细介绍。如果是编辑工作流问题，单独的内容模型可能适合。这在无头 CMS 开发下有介绍。

继续使用 Shopify 是合理的选择时

重建是对小问题的大答案。在任何人打开新仓库之前，审计一下你已有的东西。

主题体积：主题在商品页面上加载的你没要求的东西。
第三方应用：每个应用做什么、谁拥有它、是否有两个重叠。
菜单：客户是否能在没有引导的情况下找到集合。
内容工作流：编辑需要多少步骤才能发布一个登陆页面。

这是一次审计，不是预测。我不会承诺你当前主题上的每个限制都能修复，因为有些不能。审计指出哪些可以。如需结构化的性能审查，见Shopify 速度优化。

商业网站不应该仅为整理前端而改变结账和订单处理。如果订单流、付款清算和履单连接，后端就能工作。修复让你受伤的那一层。

按适配度比较真实的替代方案

下面每个平台都有最佳适用场景、重大权衡和一个测试任务。没有供应商列表，没有填充。

BigCommerce

最佳适用：你想要另一个托管商务后端，可以有也可以没有自定义前端。BigCommerce 将自己定位为无头店铺的商务后端，在那里它创建订单、处理付款、存储客户记录并检索目录和订单数据。它还提供 Catalyst、启动应用和 API。

权衡：你仍在进行平台迁移。目录、结账、订单和集成都要迁移，供应商文档确立架构。它不会降低运营成本或保证功能对等。

测试：导入一组代表性的变体，用你打算的支付网关在测试模式下完整走一遍结账，并设置运输规则。

WooCommerce

最佳适用：已经运行 WordPress 的团队，想拥有托管和代码的所有权，且有员工来管理两者。免费下载不是免费运行。查看 WooCommerce 的入门文档了解设置范围。如需更广泛的 WordPress 上下文，见WordPress 替代方案。

权衡：你继承托管、更新和插件选择。

测试：在暂存环境用你的活跃插件栈运行结账、税金计算和运输，然后更新一个插件，看看会破坏什么。

Medusa

最佳适用：需要自定义商务工作流的工程师。Medusa 将自己描述为无头商务平台，请求通过 API 路由、工作流、模块和数据存储。它支持 PostgreSQL 作为数据库，第三方服务通过商务和基础设施模块连接，Stripe 和 ShipStation 是文档化的例子。在决定自定义开发需要在哪里前，针对每项要求检查 Medusa 现有的模块和集成。它的文档包括从 Shopify、WooCommerce 和 Magento 的迁移指南。

权衡：你的团队拥有工程和运营。这就是重点，也是成本。

测试：搭建一个你今天无法管理的笨拙工作流，加上一个付款和一个履单集成，然后再做决定。

Squarespace

最佳选择：一个真正更简洁的店面和目录。我的评估：它不是复杂商务的默认选项。

权衡取舍：你用简洁性换取深度，所以现有设置中的任何定制功能都需要提前检查。

测试：以 Squarespace 的产品导出文章作为基准，然后针对它测试你的活跃变体、配送规则和订单流程。

哪些数据会迁移，哪些需要单独处理？

Shopify 支持产品 CSV 导入和导出，可以处理与其他平台的基本产品数据交换。产品 CSV 不是业务备份。Shopify 明确了限制条件：

产品 CSV 导入/导出不支持变体元字段，但定义后的产品元字段可以支持。
库存数量列仅适用于单地点门店。多地点门店使用库存 CSV。
市场列仅在市场的某个活跃目录未与其他市场共享时出现。
更改 Option1 值数据会生成新的变体 ID，这可能会破坏第三方对它们的依赖。
不能通过导入产品 CSV 来创建礼卡。该声明是关于导入到 Shopify，因此请将礼卡视为任何一个方向的单独工作。

客户 CSV 文档增加了进一步的约束。客户导出包含营销同意字段，涵盖电子邮件、短信和 WhatsApp，记录为是或否。它们还包含有限范围的元字段类型。超过 50 个客户的导出通过电子邮件发送。订单历史无法通过客户 CSV 导入，Shopify 表示你无法通过 CSV 从另一家门店迁移客户密码。该警告适用于迁移到 Shopify。不要将其理解为导出的保证：验证你的目标平台接受什么。

独立映射这些元素：订单、评价、折扣、订阅、应用数据、媒体、营销同意和配送连接。客户身份验证和支付安排需要针对目标和提供商的单独迁移计划。不要假设存储的支付详情或密码会转移。

建立范围工作表而不是价格比较

我不会引用套餐价格或估计节省费用。这些数字变化很快，唯一相关的数字是你自己的。审核你的项目清单。

你实际使用的店面模板。
目录规则：变体、捆绑包、元字段、定价逻辑。
市场和货币。
集成：ERP、CRM、PIM、配送、电子邮件、评价。
业务工作流：退货、退款、批发、订阅。

在每个项目旁边，分配谁在上线后维护它。比较订阅、应用、托管、初始构建和持续工程的运营成本。无头构建将预算重新分配给开发人员，Shopify 也认可这一点。开源将支出转向托管、安全和补丁。托管平台将支出集中在订阅和应用中。任何架构都不会将总成本降至零。支出只是转移。

在切换前验证迁移

将这些视为验收检查。它们不保证稳定的搜索排名或转化率，没有可信的工程师会承诺这一点。

URL 和 SEO：保留或映射产品、集合和内容 URL。检查重定向、元数据、规范标签、产品结构化数据和媒体。
购买路径：测试代表性变体、库存、购物车、结账、支付方式、税收和配送规则，以及退款。
客户和运营：检查客户访问、配送、营销同意、跟踪和目标地的交易电子邮件。

然后这个序列：

协调源和目标之间的数据计数。
为在构建期间创建的订单和客户规划最终数据同步。
在你信任新设置之前，保持一条可操作的回滚路线。
启动后监控错误和销售。

将你当前的店面、目录和集成列表带来确定实际需要转移的内容。

Shopify 替代方案:哪一层需要替换?