服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- fulfillmentGroupsLocationRankingAdd 可将一份地点排序应用到列出的多个履约组，减少重复输出；本次能力来自 unstable 文档。
- 订单路由地点规则 API 仍标为 Beta，须由 Shopify Plus 商家申请；部署自有自定义应用与地点规则还要求加入 Partners 计划。
- 地点按 rank 值升序选择优先级，rankings 数组里的先后位置不决定排序。
- 同一组同一地点被多次排序时，后面的 operation 覆盖前面的 rank；后项没列出的地点保留之前的 rank。
- 不属于某组的库存地点及未知组 handle 会被忽略，没有任何 operation 排名的库存地点放到最后。
哪些商家和 API 版本可以使用？
Shopify 2026 年 11 月 5 日的开发者更新列出“多履约组共用地点排序”，链接指向 unstable 版本的 Order Routing Location Rule Function API。unstable 是尚未稳定的开发版本，不能据此认定当前 stable 版本也具有同样字段。
该 API 正文仍标为 Beta，并说明只有 Shopify Plus 商家可提出使用申请。商家若要部署自己的自定义应用及地点规则，还必须加入 Partners 计划；Plus 订阅本身不等于申请已获批准。
本次查到的能力说明未给出稳定版上线日、完整国家清单或该能力的单独费用。接入前按自己的店铺、应用及所选版本核对这些条件，不把未列价格当作免费承诺。
共享排序解决什么问题？
履约组是购物车中需要一同配送的一组商品。过去若每组都返回一次 fulfillmentGroupLocationRankingAdd，相同仓库排序会反复出现在输出中；官方说明，输出随组数增长，可能超过 Function 的输出大小限制。
新操作 fulfillmentGroupsLocationRankingAdd 接收 fulfillmentGroupHandles 列表和一份 rankings，将这份排序应用到列出的每个组。结果等同于为各组分别返回单组操作，但共享的排序只需发送一次。
只有排序逻辑确实相同时才适合共用。如果不同商品或组需要不同优先级，应保留相应例外，不能为缩短输出而把业务规则合并。组和地点的 handle 由 Shopify 生成，应从 Function 输入中读取。
rank、忽略和漏列规则怎么判断？
rank 是数值优先级，Shopify 按升序使用：例如 0 排在 1 前面。调整 rankings 数组中条目的位置，不会改变各条已有的 rank 值，因此不能用数组顺序代替排序字段。
一份共享排序可以包含多个组的库存地点。Shopify 会为每组跳过不属于该组的地点；不匹配当前购物车任何履约组的 handle 也会被跳过。没有报错不等于预期的每一组或地点都实际参与了排序。
某组中没有被任何 operation 排名的库存地点会排在已排名地点之后。验证时要同时检查“实际输出了什么”和“输入里哪些有效地点没有被任何操作覆盖”，避免把漏列误认为禁用该地点。
先共享、再逐组覆盖时，哪些值会保留？
Shopify 按返回的 operations 顺序应用操作。同一履约组中的同一地点若出现多次，后面操作的 rank 替换前面的值；后项没有列出的地点仍保留已有 rank。后项不是自动清空该组的全部排序。
假设两个组都先共享“仓库 A 为 0、门店 B 为 1”。若第二个组需要反过来，应在共享操作之后，为该组返回单组操作，并明确列出“门店 B 为 0、仓库 A 为 1”。这是说明覆盖行为的假设示例，不是真实商家或仓库数据。
如果只把门店 B 改为 0，却不列仓库 A，仓库 A 会保留原来的 0，可能形成并列。要完全替换某组的排序，应在后面的单组操作中列出该组所有需要排序的地点。
不要把 API 能力当作所有销售渠道都支持
官方兼容表对不同场景分别列出支持范围。订单编辑的 Admin 场景只对新增商品部分支持；POS 仅在发货给客户时部分支持；Storefront 的部分支持限定为 Buy with Prime。
Order Edit 的 Checkout 场景、Pre-order and Try Before You Buy，以及订阅的续期订单列为不支持。已有应用即使能够返回合法排序，也仍需按实际订单来源核对兼容范围，不能由普通结账测试推定所有渠道可用。
接入前按什么顺序验证？
先确认 Beta 申请、Plus 与 Partners 条件，以及应用实际使用的 API 版本。保存一组可重复的隔离测试输入，覆盖相同排序的多个组、不同库存地点、未知组 handle 和需要例外排序的组。
接着逐项核对输出大小、rank 值、operations 顺序、被跳过的地点、漏列地点及覆盖后的最终优先级，再检查其他 locationRule 与实际销售渠道的影响。不要只凭 Function 没报错就扩大使用范围。
最后在自己获准的测试流程中核对后续地点选择和履约状态，并保存版本与结果。这些是验证建议；本文没有部署商家应用、调用店铺 API、处理真实订单或证明任何店铺已经迁移成功。
资料来源
常见问题
对应的 Function run target 是什么？
本次官方文档列出 cart.fulfillment-groups.location-rankings.generate.run。应同时确认所选 API 版本的输入输出 schema，不要把目标名称相同当作所有版本字段相同。
多个 locationRule 都返回排序时怎么办？
官方说明先按 locationRule 的优先级排列各 Function 输出，再用第一份输出中的 rank 排序；如果有并列，再用下一份输出的 rank 解开并列。没有并列时只考虑第一份输出。
组 handle 能直接当作固定业务配置长期保存吗？
文档说明组和地点 handle 由 Shopify 生成，Function 从当前输入读取。示例中的值是示例，不应直接替代当前调用的输入；需要持久业务标识时，应按对应 API 的正式字段另行设计。