Shopify Collections 改版：商品陈列正在变成运营系统

图源：Shopify Enterprise Blog，Collections 新后台体验

Shopify Collections 不再只是商品分组

2026 年 7 月，Shopify 对 Collections 做了一次重要升级。

这次更新来自 Shopify Enterprise Blog、Shopify Changelog 以及 Shopify developer changelog。官方信息显示，Collections 现在支持多来源、变体级集合、集合嵌套复用，并可用于折扣、税务等更多业务流程。

过去，Collections 更像是店铺前台的商品分组工具。现在，它开始承担商品陈列、活动规则、业务流程复用之间的连接层角色。

对 Shopify 商家、独立站运营、跨境服务商和开发者来说，这次变化不止是后台多了几个按钮，商品组织方式、营销配置方式、App 兼容方式都会随之调整。

先给一个判断：小 SKU 店铺短期不用重建 Collections；如果你依赖活动集合、折扣集合、POS / Online Store 同步，建议重新检查集合结构；如果你维护 App 或定制功能，重点看 2026-07 GraphQL Admin API 的变化。

过去的问题：集合能力够用，但不够灵活

在以往的 Shopify 商品集合体系里，商家通常通过两种方式创建 Collection：基于条件自动生成，或手动选择商品。前者适合标签、价格、标题、库存等规则，后者适合专题页、活动页、人工 curated 场景。

这套模型能支撑基础陈列，但一旦运营场景变复杂，就很容易遇到边界。比如一个促销集合既要自动纳入符合条件的商品，又要手动置顶重点新品，还要排除低库存或不参加活动的商品；再比如只想展示某个颜色、尺码的变体，而非整个商品。

过去这些需求往往依赖复制集合、额外标签、人工维护，或第三方 App 做补充。新 Collections 模型的方向，是把更多商品陈列规则收回到 Shopify 原生体系里。

新能力一：一个 Collection 可以有多个来源

图源：Shopify Enterprise Blog，多来源集合配置示意

新版 Collections 支持 multiple sources。商家可以在一个 Collection 中组合自动条件、手动选择的商品、排除条件、其他 Collections，以及来自 App 的来源。

这对运营的意义很直接：一个集合不再只能对应一条简单规则，而可以承载更完整的商品策略。

例如，一个“夏季促销”集合可以自动包含标签为 summer 的商品，同时手动加入重点新品，引用另一个“高毛利商品”集合，并排除已经断码或不参加活动的商品。过去类似配置通常会拆成多个集合或依赖标签体系，现在可以在 Collection 这一层完成更多规则组合。

这种变化会减少重复维护。运营不必为了每个活动复制一套商品列表，也不必在多个地方反复同步商品范围。

新能力二：支持变体级 Collections

图源：Shopify Enterprise Blog，变体级集合展示示意

另一个关键变化是 variant-level collections。Shopify 现在允许围绕具体变体创建集合，比如某个尺码、颜色、规格，不必只能把整个商品放进集合。

这对服饰、鞋履、美妆、消费电子配件等行业影响很大。一个 T 恤商品可能有黑色、白色、灰色三个颜色。过去如果只想把黑色款放进“黑色系穿搭”专题，前台往往还是以商品为单位展示，运营需要通过主题逻辑、标签或 App 做额外处理。

变体级集合上线后，集合可以直接围绕特定 variant 构建。Shopify 官方说明中提到，这些变体会出现在 collection pages、filters，以及支持的销售渠道中，包括 Online Store、POS 和 Shop。商品陈列粒度由此从“商品级”进一步细化到“SKU / variant 级”。

新能力三：Collections 可以成为积木

新版 Collections 支持将一个 Collection 作为另一个 Collection 的来源。这项能力让 Collections 具备了“积木化”的特征。

比如“新品”“高毛利商品”“夏季主推”可以分别作为不同层级的集合存在。上层集合引用基础集合后，当基础集合发生变化，上层集合也能同步更新。

对大 SKU 店铺来说，这比复制商品列表更可靠。运营可以沉淀基础集合，再在活动、频道、区域、季节等场景中复用。服务商在设计商品架构时，也需要把集合看作可复用的运营模块，而不只是前台导航的一部分。

新能力四：同一集合可用于折扣、税务等流程

Shopify 官方提到，新 Collections 可在支持的业务工作流中复用，例如 discounts 和 taxes，并且包括 variant-level collections。

这点对跨境独立站尤其重要。过去，店铺前台陈列、折扣规则、税务规则可能使用不同条件维护。页面上显示的是一组商品，折扣覆盖的是另一组商品，税务或合规规则又可能是第三组商品。

当 Collections 变成可复用的业务对象后，商家可以用同一套集合逻辑支撑多个流程，减少重复配置，也降低活动上线时的规则错配风险。

后台体验：从列表管理走向可视化陈列

这次更新还包括 redesigned collections admin UI。Shopify 官方列出的后台变化包括 visual grid、drag-to-reorder、bulk moves、list view，以及控制 customer-facing sort order。

也就是说，运营可以在可视化网格中拖拽排序，批量移动商品，同时保留列表视图查看细节，并控制顾客在集合页看到的排序。

Collections 页面的商品顺序，很多时候并不只是“按时间”或“按销量”。运营会根据库存、毛利、上新节奏、广告投放、转化率去调整首屏商品。可视化排序降低了这类工作的操作成本。

Shopify 还提到，Sidekick 支持创建和更新 Collections，覆盖 admin 和 mobile。未来部分集合配置可能通过自然语言完成，例如让 Sidekick 帮忙创建某个活动集合或调整规则。

对商家的影响：商品运营会更集中

对 Shopify 商家来说，这次升级的主要价值在于减少绕路。过去一些需要第三方 App、复杂标签体系或重复集合维护的场景，现在可以更多放到原生 Collections 里完成。

活动专题页、新品和清仓集合、特定颜色或尺码专题、BFCM 和节日大促、POS 与 Online Store 的商品范围统一，以及折扣、税务、合规规则中的商品圈选，都会受到这次升级影响。

商家需要重新审视现有 Collections 架构：哪些集合只是前台导航，哪些集合承担活动规则，哪些集合可以抽象为可复用的基础模块。店铺 SKU 较少时，短期影响可能有限；如果店铺有大量 SKU、多个市场、多渠道销售，Collections 的设计会变得更重要。

对运营团队的影响：集合要被当作规则资产管理

Collections 能力增强后，也会带来新的管理要求。一个集合可能由多个来源、多个条件、排除规则、子集合组成。它的含义比过去更丰富，也更需要命名规范和维护纪律。

第一，建立集合命名规范。建议区分前台导航集合、活动集合、折扣集合、税务或规则集合、基础复用集合。当 Collections 被用于更多业务流程后，混乱命名会直接增加误操作风险。

第二，控制集合嵌套层级。集合可以引用集合，但不代表应该无限嵌套。过深的依赖关系会让运营难以判断某个商品为什么进入或离开集合。服务商在搭建方案时，需要在复用能力和可解释性之间做平衡。

第三，记录关键集合用途。如果一个 Collection 同时用于前台页面、折扣规则和税务规则，团队内部需要清楚它的业务含义。否则后续修改集合条件时，可能影响多个流程。

对开发者的影响：GraphQL Admin API 模型已变化

开发侧变化更具体。Shopify developer changelog 2026 年 6 月 17 日发布的《New Collection model and APIs now available》说明：在 2026-07 GraphQL Admin API 中，Collections 使用 multi-source model 替代原来的单一 ruleSet 模型。

新的关键字段是 Collection.sources。它返回一个或多个支撑该 Collection 的 CollectionSource 对象。目前有两个具体类型实现新的 CollectionSource interface：CollectionConditionsSource 和 CollectionSubCollectionsSource。

CollectionConditionsSource 可通过 typed inclusion conditions 和 manual selections 纳入商品，也可以通过 exclusion conditions 排除商品。每个 source 必须指定 target：PRODUCTS 或 VARIANTS。匹配条件由 CollectionConditionMatchType 控制，ANY 表示满足任一条件，ALL 表示满足全部条件。

这套模型比旧 ruleSet 更接近可组合的规则结构，也能表达过去 legacy shape 无法表达的能力，比如 multiple sources、exclusion conditions、sub-collections、shareable sources。

App 需要关注 API 版本和数据可见性

在 2026-07 API 中，collectionCreate 和 collectionUpdate 支持新的 input。CollectionUpdateInput 提供 sourcesToCreate、sourcesToUpdate、sourcesToDelete，开发者可以增量更新 sources，而不必替换整个 collection 定义。

旧的 collectionCreate(input:) 和 collectionUpdate(input:) 已被标记为 deprecated，但在 2026-07 中仍可使用，方便开发者逐步迁移。如果同时传入旧 input 和新 collection argument，新 collection argument 优先。

Shopify 还明确说明：在 2026-07 及之后版本中，使用新 sources model 的 collections 会通过 collections queries、collection(id:) lookups 以及其他返回 collection 的字段返回。但在更早 API 版本中，使用新能力的 collections 会被过滤掉，因为旧 ruleSet 结构无法表达它们。

这意味着，如果 App 仍停留在旧 API 版本，可能出现商家后台已经创建了新模型 Collections，但 App 查询不到或无法正确管理的情况。对依赖 Collections 的 App 来说，这已经超出单纯字段升级的范围，直接关系到数据可见性。

Shopify Functions 增加变体级集合判断

开发者 changelog 还提到，Shopify Functions 的 ProductVariant 类型新增 inAnyCollection(ids: [ID!]!) 和 inCollections(ids: [ID!]!) 字段，用于判断 variant-level collection membership。

原有 Product.inAnyCollection 和 Product.inCollections 继续保留产品级集合判断。区别在于，变体只有在自身被纳入集合时，才会被视为该 variant-level collection 的成员。

这对折扣、定价、税务、运费、校验类 Functions 都有潜在影响。开发者需要明确规则判断对象是 product 还是 variant，避免把产品级 membership 误用到变体级场景。

现有 Collections 不需要重建，但要检查依赖

Shopify 官方说明中也给出了商家关心的兼容性信息：现有 collections 会继续工作，并自动更新到新的 admin experience，不需要删除或重新创建。

不过，如果店铺使用了第三方或定制 App 与 Collections 交互，Shopify 建议让开发者更新到 API version 2026-07，以支持这些新能力。

如果 App 会读取 Collections、创建或更新 Collections、基于 Collections 做折扣或推荐、读取 Collection.ruleSet、写入 input.ruleSet，或者在 Functions 中判断商品是否属于某集合，就需要尽快评估兼容性。

这次改版的核心变化

这次 Collections 升级可以从三个层面理解。

第一，商品范围的表达能力增强。Collections 已经不局限于单一自动规则或手动商品列表，可以组合多个来源、排除条件、子集合和 App 来源。

第二，商品陈列粒度更细。Variant-level collections 让运营可以围绕颜色、尺码、规格等变体组织商品。

第三，Collections 成为可复用的业务规则对象。同一个集合可以进入前台陈列，也可以进入折扣、税务等流程，减少多处重复维护。

对商家来说，这是运营效率提升；对开发者来说，这是 API 模型迁移；对服务商来说，这是店铺商品架构设计方式的变化。

Shopify Collections 过去更像一个商品分组工具。现在，它开始承担商品陈列、活动规则、业务流程复用之间的连接层角色。