Saleor：GraphQL 原生的无头电商后端

接「做一个独立电商站」的单子，选型时真正要定的是「后端管到哪、前端谁来定」。公众号「寻微一隅」10 月 15 日清单把 Saleor 放在单价最高的平台建设层：它是一个只通过 GraphQL API 交互的开源电商后端（Python，BSD-3-Clause，截至 2026-10-15 约 23.4k star）——商品、订单、支付、促销都在 API 后面，前端用什么框架、长什么样，全部由交付方决定。

核心功能

• GraphQL only：后端只暴露 GraphQL 一种接口，没有 REST 与内部接口并存的「两套真相」，类型系统即契约。
• 无头 + API only：配置、扩展、运营全部通过 API 完成；Dashboard 是独立的前端项目（saleor-dashboard），商店端同样自选。
• 渠道模型原生：按 channel 分别控制定价、货币、库存与商品——一个后台管多市场、多币种，不用起多个实例。
• 扩展机制替代插件：webhook、同步/异步事件、subscription query、metadata、dashboard iframe 应用；应用独立部署、独立扩容，升级时不再被插件兼容性卡住。
• 商业模型完整：商品与 CMS、灵活订单（拆分支付、多仓库、退货）、客户、促销引擎（购物车规则、优惠券、礼品卡）、支付编排（多网关、可扩展 API）。
• 文档与云并存：官方托管云 cloud.saleor.io 与自托管两条路，README 明确「单一版本、无商业功能阉割」。

典型使用场景

• 接出海电商站的开发者：前端要 Next.js 或 Nuxt 自定义结账流程，后端用 Saleor 管订单与库存，GraphQL 一次取齐结账页所需数据。
• 要多市场运营的品牌方：一个 channel 一个市场，定价、货币、库存按渠道隔离，比维护多套后台便宜。
• 已有设计系统、要深度定制购物流的团队：无头意味着界面不受模板约束，代价是前端工作量全在自己身上。

快速上手

自托管从 Docker Compose 起步，官方文档按环境给出步骤；想先看 API 形态，最快的路径是注册 cloud.saleor.io 的试用，用 GraphQL Playground 直接查商品与订单：

query {
  products(first: 5, channel: "default-channel") {
    edges {
      node {
        id
        name
        pricing {
          priceRange {
            start {
              gross {
                amount
                currency
              }
            }
          }
        }
      }
    }
  }

商店端从零搭：选一个前端框架，接 Saleor 的 GraphQL 与 Storefront API，结账、支付、订单回查都走同一套 schema；Dashboard 可以直接用官方的 saleor-dashboard。

小结

适合「要完全控制前端、又要一个不阉割的电商后端」的团队和接单开发者；不适合小商家快速上线——README 自己点明 tradeoff：单人小项目、流量不高、不需要 7×24 可用性时，服务式架构会比 WordPress 或 Magento 那类「开箱即用」方案更重。Python，BSD-3-Clause，截至 2026-10-15 是 23441 star、当天仍有推送，项目活跃。

同赛道里 Medusa 是另一个常被对照的开源无头电商（README 的 suggest 联想里 saleor vs medusa 是真实搜索变体）；要的是「博客 + 付费墙」而不是完整交易链路，Ghost 更轻。