Shopify Liquid API与Storefront API差异咨询：Collection的all_types字段缺失

是否遗漏了相关配置？ #

没有遗漏任何配置——Storefront API的GraphQL端点确实没有直接提供类似Liquid中all_types的字段，这并非配置问题，而是两个API的设计差异导致的。

如何通过Storefront API获取集合的所有商品类型？ #

你需要通过嵌套查询先获取集合下的商品，再提取并去重productType字段。示例查询如下：

query GetCollectionProductTypes($collectionHandle: String!) {
  collection(handle: $collectionHandle) {
    products(first: 250) {
      edges {
        node {
          productType
        }
      }
      pageInfo {
        hasNextPage
        endCursor
      }
    }
  }
}

如果集合内商品数量超过250个，需要按分页逻辑循环获取全部数据，之后在前端用JavaScript去重得到唯一的商品类型列表：

// 假设products是已获取的所有商品节点数组
const uniqueProductTypes = [...new Set(products.map(item => item.productType))];

为什么Liquid API和Storefront API存在这种差异？ #

两者的设计定位和目标场景不同，导致了数据返回的差异：

• Liquid API为主题渲染优化：Liquid是Shopify专为主题服务端渲染打造的模板引擎，all_types是提前在服务端聚合好的字段，目的是简化主题开发者的模板逻辑，比如快速实现筛选栏的类型选项。
• Storefront API遵循GraphQL按需取数原则：它的核心是让开发者按需获取精准数据，避免冗余。如果直接提供聚合后的all_types，会限制自定义需求（比如需要同时获取类型对应的商品数量时，预聚合字段就无法满足），把聚合逻辑交给客户端处理反而更灵活。
• 性能与扩展性考量：服务端预聚合all_types会消耗额外计算资源，Storefront API将这类聚合逻辑转移到客户端，既减轻了Shopify服务器的负载，也让开发者能根据自己的业务场景做优化（比如缓存去重后的类型列表）。

内容的提问来源于stack exchange，提问作者Max