面向开发者的 5 款开源电商平台

对于在 2026 年构建 headless 店面的前端工程师而言，目前值得评估的最优秀开源商务后端包括 Medusa、Saleor、Vendure、Sylius 和 Shopware。这五个平台均以 API 优先为设计理念，持续活跃维护，并能与 Next.js 或其他基于 React 的店面无缝集成——但它们在语言运行时、API 形态（REST vs GraphQL）、许可证模型以及自托管运维负担等方面存在显著差异。本文旨在帮助你从中筛选出最适合的一款，毕竟你即将为此投入数周的集成工作和数年的维护精力。

WooCommerce、Magento 和 PrestaShop 在此值得客观提及：它们是成熟、广泛部署的生态系统，拥有庞大的插件市场和商家工具，这是以下平台目前尚未企及的。但它们的核心定位是 WordPress/管理模板体系，而非基于 TypeScript 编写的 API 驱动型店面。如果你的店面是一个调用类型化 SDK 或 GraphQL 端点的 Next.js 应用，以下五个平台才是真正相关的候选名单。如果你的店面是由营销团队管理的主题化 CMS 站点，那本文并不适合你。

Headless 商务架构早已不再是一个需要被推销的趋势——在当下，它已成为全新店面项目的默认架构选择。问题不再是是否要将店面与商务引擎解耦，而是哪个引擎能在后续数年的功能迭代中为你提供最佳的开发体验。

如何选择：对比表格

缩短候选名单最快的方式，是从店面开发者真正关心的维度将各平台并排对比。下表汇总了五个候选平台；Star 数量和版本号持续变化，因此请将其作为起点，在做出决定前务必到各项目的 GitHub Releases 页面核实最新信息。

平台	主要语言 / 运行时	架构	API 模型	开源许可证	默认店面	自托管基础设施	官方 / 推荐 Next.js Starter
Medusa	TypeScript / Node.js	Headless，模块化（v2）	REST 优先 API	MIT	Next.js starter	Node + PostgreSQL + Redis	是（官方）
Saleor	Python / Django	Headless	仅 GraphQL	BSD-3-Clause	React 店面示例	Python + PostgreSQL + Redis + Celery worker	是（官方 Next.js 示例）
Vendure	TypeScript / NestJS	Headless	GraphQL（Shop + Admin API）	MIT（核心）	Remix + Next.js 社区 starter	Node + PostgreSQL/MySQL	社区 starter
Sylius	PHP / Symfony	混合型（服务端渲染 + 通过 API Platform 提供 REST/GraphQL）	REST + GraphQL	MIT	Twig 店面，可选 headless	PHP + MySQL/PostgreSQL	社区示例
Shopware	PHP / Symfony + Vue.js	混合 headless	REST Store API + Admin API	MIT（核心）	Vue.js 店面，可选 headless	PHP + MySQL + Elasticsearch/OpenSearch	社区 starter

有两列值得重点关注。许可证列并不能反映全貌：Vendure 和 Shopware 均提供 MIT 许可的核心版本，完全具备生产可用性，同时另有独立许可的商业托管平台产品。这是评估预算时需要了解的特性，而非某种陷阱——开源核心无需付费即可正式使用。自托管基础设施列反映了你在生产环境中需要运维的最少服务数量，Saleor 在这一点上与基于 Node 的选项存在明显差异。

Medusa——基于 Node.js/TypeScript 的 Headless 商务平台，支持 v2 模块与工作流

Medusa 是一个 Node.js/TypeScript headless 商务后端，其 v2 版本将平台重构为围绕独立商务模块的架构——包括商品、购物车、订单、库存、定价——每个模块均可替换为自定义实现或第三方服务。模块与工作流架构详见官方 v2 文档。

对前端工程师而言，这使 Medusa 成为五个平台中可组合性最强的选择。店面代码通过类型化的 JavaScript 客户端与 Medusa 服务端通信；后端定制通过编写 TypeScript 模块和工作流来实现，这些代码可以与团队其他服务共存于同一个 monorepo 中。Medusa 文档中提供的官方 Next.js starter，只需一条 create-medusa-app 命令即可获得包含购物车、结账和账户流程的完整可用店面。

Medusa 的突出优势：

• 端到端类型对齐。 服务端是 TypeScript，店面 SDK 是 TypeScript，自定义模块也是 TypeScript。schema 与店面类型之间无需额外的代码生成步骤。
• 工作流（Workflows）。 Medusa v2 为多步骤商务操作（下单、退货等）提供了显式的工作流原语，使长时运行和可补偿的逻辑比隐式事务链更易于理解和维护。
• 本地开发简单直接。 单个 Node 进程配合 PostgreSQL，加上用于后台任务的 Redis 即可运行。

Medusa 需要注意的地方：

• REST 优先。 Medusa 的主要 API 是 REST。希望使用单一 GraphQL 端点和 codegen 驱动类型的店面团队会发现 Saleor 更为自然。
• v1 → v2 迁移。 仍在使用 Medusa v1 的代码库面临非轻量级的迁移工作；模块系统、管理后台和 API 均发生了实质性变化。

选择 Medusa 的场景： 团队以 TypeScript 为主要技术栈，希望用自己熟悉的语言完全掌控定制化，且 REST + 类型化 SDK 的开发体验适合你的团队。不适合 Medusa 的场景： 你需要纯 GraphQL 数据层，或者需要在第一天就拥有功能完善的开箱即用管理后台和商品运营工具集。

Saleor——基于 Python/Django 的 GraphQL 优先 Headless 商务平台

Saleor 是一个 Python/Django headless 商务平台，采用 GraphQL 优先的 API 设计。所有商务操作——商品查询、结账 mutation、订单管理、客户账户——均通过单一的版本化 GraphQL 端点处理，详见 Saleor API 参考文档。代码库采用 BSD-3-Clause 许可证，详见 GitHub 上的 LICENSE 文件。

GraphQL 优先的设计在店面层面体现得最为明显。Next.js 店面可以使用 urql、Apollo 或 graphql-request 将数据需求与组件并置，针对 Saleor 的 schema 运行 graphql-codegen，无需编写单独的 REST 适配层即可获得完整类型化的查询和 mutation hooks。一个典型的商品页面查询如下：

query ProductBySlug($slug: String!, $channel: String!) {
  product(slug: $slug, channel: $channel) {
    id
    name
    slug
    description
    variants {
      id
      name
      quantityAvailable
    }
  }
}

这个单一查询精确返回页面所需渲染的数据——无过度获取，无需单独的库存调用，也不存在与服务端货币格式逻辑产生偏差的价格格式化辅助函数。Saleor 还发布了官方 Next.js 店面示例（storefront 仓库），可直接 fork 而无需从零构建。

Saleor 需要注意的地方：

• 运维基础设施。 自托管 Saleor 需要 Python、PostgreSQL、Redis 以及用于异步任务的 Celery worker 进程。这比 Node + PostgreSQL 的组合更重，如果团队尚未运维 Python 技术栈，需提前评估。
• Schema 版本管理纪律。 GraphQL 优先平台意味着 breaking schema 变更是可见的。Saleor 发布新次版本时附有清晰的迁移说明，但未锁定 schema 版本并重新生成类型的店面在升级后可能遭遇静默故障。

选择 Saleor 的场景： 你需要单一 GraphQL 端点，能够接受运维 Python 技术栈，且店面团队熟练掌握 GraphQL 客户端和 codegen 工作流。不适合 Saleor 的场景： 团队没有 Python 运维经验，且希望将整个技术栈保持在 Node 上。

Vendure——基于 TypeScript/NestJS 的框架，MIT 核心版本与商业 Platform 版本并行

Vendure 是一个基于 TypeScript/NestJS 的 headless 商务框架，提供 GraphQL API 和基于 Angular 的管理后台。它是本次对比中唯一一个以 TypeScript 实现插件 API、服务层和 GraphQL schema 扩展并提供完整类型推断的平台——这意味着自定义插件和店面代码共享同一套语言和类型模型。Vendure 文档 涵盖了插件系统、Shop/Admin 双 GraphQL API 以及数据模型的详细说明。

Vendure 的开源核心（MIT 许可）是一个功能完整的 headless 商务引擎。商业版 Vendure Platform 提供托管服务、企业支持和附加模块，但运行生产店面并不需要购买该版本。在采用之前，理解这一区别至关重要：核心版本是真正完整可用的，“开源”并不意味着”功能受限的演示版”。

从店面角度来看，Vendure 暴露两个 GraphQL API——Shop 用于公开的店面操作，Admin 用于后台管理工具。两者均支持 introspection 和 codegen。NestJS 作为服务端底层框架，意味着自定义插件遵循熟悉的模块-提供者模式，对有 NestJS 背景的团队尤为友好。

Vendure 的突出优势：

• 全栈 TypeScript。 服务端、插件、管理 UI 扩展和店面——统一的类型系统贯穿始终。
• 清晰的插件架构。 自定义字段、生命周期钩子和 GraphQL schema 扩展均为一等公民，而非后期拼凑的功能。
• 轻量级自托管。 单个 Node 进程配合 PostgreSQL 或 MySQL。本地开发默认使用 SQLite，上手流程极为简洁。

Vendure 的权衡取舍：

• 生态系统规模较小。 与 Saleor 或 Medusa 相比，第三方插件和集成目录较少。你需要自行编写更多的胶水代码。
• 管理后台基于 Angular。 如果团队计划深度定制管理 UI 且只熟悉 React，这将带来额外的技术切换成本。

选择 Vendure 的场景： 你希望拥有最具 TypeScript 原生特性、类型安全的 headless 商务技术栈，并愿意自行构建部分集成。不适合 Vendure 的场景： 你需要从第一天起就拥有最广泛的插件市场，或者无法接受基于 Angular 的管理后台。

Sylius——基于 Symfony 的商务框架，通过 API Platform 提供 REST 和 GraphQL

Sylius 是一个基于 Symfony（PHP）构建的开源电商框架。它定位为框架而非开箱即用的平台：提供商务原语（商品、渠道、订单、促销、购物车），并假设你会将其组合成业务实际所需的应用程序。Sylius 文档 涵盖了组件模型和 Symfony bundles 的详细说明。

对前端工程师而言，Sylius 的价值在于其 API 层。Sylius 与 API Platform 集成，在其数据模型之上暴露 REST 和 GraphQL 端点，使其可作为 Next.js 或其他 JavaScript 店面的 headless 后端使用。默认店面使用 Twig 模板——对传统构建方式完全适用，若选择 headless 方案则可忽略。

Sylius 的突出优势：

• Symfony 生态深度。 如果你的团队熟悉 Symfony，Sylius 比本文中任何其他平台都能更自然地融入更广泛的 PHP 企业生态系统。
• 通过框架惯用模式进行定制。 使用标准 Symfony 模式覆盖服务、事件和实体，无需学习专有插件 DSL。
• MIT 许可，无需商业版本。 你构建的基础是完整的 MIT 许可 Sylius 代码库。

Sylius 的权衡取舍：

• PHP 运行时。 没有 PHP 运维经验的 Next.js 团队需要为后端引入 PHP-FPM、Composer 和 Symfony 工具链。
• 需要更多自行组装。 Sylius 坦诚地将自身定位为框架。与 Medusa 或 Saleor 相比，要达到开箱即用平台的功能对等，你需要编写更多代码。

选择 Sylius 的场景： 团队内部具备 Symfony 专业能力，且希望拥有一个可以完全按照业务领域塑造的商务框架。不适合 Sylius 的场景： 团队仅使用 JS 技术栈，且不希望在 Node 服务旁边运维 PHP 运行时。

Shopware 6——PHP/Symfony 后端，深度商家工具与 Vue.js 店面

Shopware 6 的 MIT 许可社区版是一个功能完整的商务后端，同时支持传统部署和 headless 部署，在基于 Vue.js 的店面框架之外还暴露了 REST Store API。商业版 Rise、Evolve 和 Beyond 计划提供托管服务、高级 B2B 功能和企业支持，但无需商业许可证，开源核心即可用于生产环境。Shopware 开发者文档 涵盖了 Store API、Admin API 以及应用/插件系统的详细说明。

Shopware 是本次对比中商家功能最完整的平台。“Shopping Experiences” CMS 为营销页面提供了拖拽式页面构建器；规则构建器支持无需编码即可配置动态定价、配送和促销规则；管理后台工具集功能深度可观。对于构建 Next.js 店面的开发者而言，Store API 基于 REST 且文档完善，社区也提供了可直接使用的 Next.js 店面 starter。

Shopware 的突出优势：

• 开箱即用的商家工具，是上述以开发者为中心的平台所无法比拟的。
• 强大的欧洲市场地位，拥有成熟的合作伙伴生态系统。
• 混合 Headless。 可运行默认的 Vue.js 店面，也可通过 Store API 完全走 headless 路线。

Shopware 的权衡取舍：

• PHP + Elasticsearch 运维负担。 自托管比 Node 选项更重。
• 插件系统以 PHP 为中心。 即使你的店面是 TypeScript，后端定制仍需使用 PHP/Symfony。

选择 Shopware 的场景： 你需要大量开箱即用的商家功能，且能够接受运维 Symfony/PHP 技术栈。不适合 Shopware 的场景： 团队仅使用 JS 技术栈，且倾向于选择更轻量、更以开发者为中心的选项，如 Medusa 或 Vendure。

何时考虑 Spree

如果 Shopware 感觉过于企业化，且团队有 Ruby on Rails 经验，Spree Commerce 是一个合理的备选方案。它采用 MIT 许可，完全 API 驱动，支持多店铺和多供应商场景，且已发展足够成熟，Rails 相关模式已有充分沉淀。其权衡取舍与 Sylius 如出一辙：以 Ruby on Rails 替代 Symfony，但决策模式相同——以引入成熟服务端框架生态系统为代价，换取非 JS 运行时。

店面侧的决策因素

在店面集成层面，有五个因素决定了后端的开发体验是顺畅还是痛苦：TypeScript 开发体验、Next.js 兼容性、本地开发冷启动速度、插件架构以及文档深度。

TypeScript 与 codegen 开发体验。 Medusa 和 Vendure 均提供与服务端类型对齐的 TypeScript SDK，无需单独的代码生成步骤。Saleor 的 GraphQL schema 最适合通过 graphql-codegen 使用，这增加了一个构建步骤，但能生成质量优秀的类型化 hooks。Sylius 和 Shopware 则需要你自行建模 API 响应，或使用社区生成的客户端。

Next.js 兼容性。 Medusa 和 Saleor 均维护支持 App Router 的官方 Next.js 店面示例。Vendure 有社区 starter。Sylius 和 Shopware 通常通过直接 API 调用或社区 SDK 供 Next.js 店面使用——可行，但需要自行编写更多集成代码。

本地开发体验。 Medusa 和 Vendure 提供最快的冷启动——安装依赖、运行迁移、启动服务器，即可完成。Saleor 文档完善但因 Python + Redis + Celery 的要求而相对较重，推荐使用 Docker Compose。Shopware 和 Sylius 需要完整的 PHP 开发环境；Docker 镜像可以简化这一过程，但涉及的组件更多。

插件与扩展架构。 五个平台均支持自定义扩展，但开发体验各有不同。Vendure 插件是具有类型安全生命周期钩子的 TypeScript 模块。Medusa v2 模块是具有清晰契约的 TypeScript 类。Saleor 使用基于 webhook 的”apps”，以独立服务形式运行——隔离边界更强，但运维开销更大。Sylius 和 Shopware 使用 Symfony 的 bundle/插件系统。

文档质量。 在五个平台中，Medusa、Saleor、Vendure 和 Shopware 均维护着包含 API 参考、教程和架构概述的文档站点，并与版本发布保持合理同步。Sylius 的文档内容详尽，但预设读者具备 Symfony 基础知识。

任何平台都无法规避的真实生产故障

在 headless 店面中，有一种常见的生产故障模式在本文所有后端平台中普遍存在：商品页面的 React hydration 不匹配——服务端渲染的价格、库存数量或本地化字符串与客户端在获取最新数据后渲染的内容产生偏差。其他反复出现的问题包括：网络故障后客户端购物车与服务端 session 状态漂移导致的静默购物车状态不一致；支付提供商脚本（Stripe、Adyen、PayPal）加载或初始化失败，仅表现为结账按钮卡死；以及后端升级后 breaking schema 变更导致字段静默变为 null，而非抛出明显错误。

这些故障与平台无关，但可调试性因后端在 API 响应中暴露错误上下文的方式不同而有所差异。Saleor 的 GraphQL 错误携带结构化错误码；Medusa 的 REST 响应包含错误类型；Shopware 和 Sylius 则暴露 Symfony 的结构化错误格式。无论选择哪个平台，为店面接入类似 OpenReplay 的会话回放工具——用于捕获导致购物车失败或结账中断的实际 DOM 状态、网络请求、控制台错误和用户操作——都能弥合”用户反映结账故障”与”可复现的 bug 报告”之间的鸿沟。OpenReplay 的会话回放产品正是专为这类前端生产调试场景而构建的。

做出最终决策

一旦权衡了团队的语言技术栈和店面数据层偏好，候选名单会迅速收窄。以 TypeScript 为主要技术栈、构建带有类型化 SDK 的 Next.js 店面的团队，应优先评估 Medusa，其次是 Vendure。希望使用单一 GraphQL 端点且愿意运维 Python 技术栈的团队，应评估 Saleor。熟悉 Symfony 的团队，若需要框架形态的构建方式应评估 Sylius，若需要最完整的商家工具则应评估 Shopware。在做出最终决定之前，请先对你排名前一两位的候选平台运行本地快速入门——花一个下午执行 docker-compose up 并浏览管理后台，所获得的信息将远胜于再花一周时间阅读对比文章。

常见问题

我可以将 Shopify 作为这些平台的开源替代方案吗？

不可以。Shopify 是一个闭源的托管 SaaS 平台，而非开源软件。其店面主题在某种程度上是开放的，你可以编辑 Liquid 模板，用于 headless 店面的 Hydrogen 框架也采用 MIT 许可，但商务引擎本身是专有的，不可自托管。如果自托管和源代码访问是硬性要求，Shopify 与 Medusa、Saleor、Vendure、Sylius 或 Shopware 并不属于同一类别。

自托管这些平台时，如何处理 PCI 合规问题？

将持卡人数据转交给 Stripe、Adyen、Braintree 或 Mollie 等提供令牌化服务的支付提供商处理，确保原始卡号永远不触及你的服务器。本文中的五个平台均通过托管支付字段或跳转流程与这些提供商集成，这将你的 PCI 范围缩减至 SAQ A——最轻量的自评估级别。只要支付提供商负责处理持卡人数据，自托管商务后端本身并不会增加 PCI 合规负担。

我可以从 WooCommerce 或 Magento 迁移到这些 headless 平台之一吗？

可以，但请将其视为数据迁移和集成项目，而非配置变更。你需要从源平台导出商品、客户、订单和历史数据，然后通过目标平台的管理 API 或自定义导入脚本将其导入。Saleor、Medusa 和 Shopware 均提供适合批量导入的管理 API。URL 结构、SEO 重定向和客户密码哈希是最常被低估的迁移步骤。

这些平台支持多货币和多地区店面吗？

五个平台均支持多货币，但实现模型各有不同。Saleor 使用“渠道（channels）”来按地区划定货币、语言、仓库和定价的范围。Medusa v2 支持按地区配置货币、税率和支付提供商的区域（regions）。Vendure 的渠道具有类似的范围划定能力。Shopware 使用“销售渠道（sales channels）”实现相同目的。Sylius 通过其渠道系统对此进行建模。在选定平台前，请查阅各平台文档，了解价格是按货币存储还是在请求时动态转换。