Shopify 同名运费重复显示：官方澄清与应用迁移检查

同名运费为何会显示两次？先看10月14日澄清

Shopify Staff 在开发者论坛说明，分别配置的运费即使名称相同，也可以在结账时分别显示。这是逐步推出的 Market-driven shipping 行为变化；10月6日进一步确认，它也适用于尚未迁移的店铺。旧行为是合并同名费率并显示最便宜的一项，不是固定让 Shopify 手动费率优先。

10月6日的过渡说明称，原先使用同名合并的店铺应继续保留旧行为至2027年7月，并收到 Shopify admin 通知。10月14日工作人员解释，讨论中的店铺最可能因同名费率由 carrier service 动态返回而未被提前识别，未进入临时保留旧行为的群体；这是个案的可能原因，不是所有店铺的确定结论。

10月14日工作人员还确认，确有一组使用承运费率的商家漏收后台通知，并表示将请求发布 changelog。开发者此前已处理该商家的费率，因此工作人员将当下个案标为 resolved；它不表示平台撤回新行为、所有受影响店铺已修复，或 changelog 已经发布。

先核对费率来源，再决定保留哪一项

假设同一店铺手动配置了一项 Standard Shipping，承运服务又动态返回一项同名费率。名称相同不足以证明只该显示一项，更不能继续依赖旧的自动合并规则来隐藏其中一项。这个例子仅说明两种来源可能重名，不代表任何店铺的实际金额或结果。

第一步，在获授权的环境核对代表性商品与地址的实际结账选项，记录重复名称、对应来源、市场和地点。同时确认店铺当前配送模式；不要仅凭是否已经迁移，判断这次费率显示变化会不会发生。

第二步，到实际配送设置或承运应用中核对两项是否都应提供。可用不同名称帮助区分；不需要的费率应从对应设置停用或移除，或在店铺与应用具备相应条件时用 delivery customization 隐藏。改名与隐藏是不同动作，不能假设改成同名就会恢复旧合并。

第三步，比对调整前后的结账选项，避免把本应保留的配送服务一并移除。若依赖旧合并却没有收到通知，或具体店铺仍出现异常，把费率来源、时间和必要的店铺证据交给 Shopify 支持核对。论坛没有给出各方案的通用权限、统一修复时限或补偿承诺。

应用是否需要迁移，取决于读写谁的配置

2026年7月1日开发者公告与既有升级指南说明，商家自有配送配置会转入 Markets；deliveryProfile 与 deliveryProfiles 对商家配置逐步弃用，而应用自有 profile 继续使用现有 API。

检查 GraphQL 查询和 mutation 中的 deliveryProfile、deliveryProfiles、deliveryProfileCreate、deliveryProfileUpdate、deliveryProfileRemove，并标出每次操作的是商家 profile 还是应用创建的 profile。

只创建、维护应用自有 profile 且不读取商家 profile，无需因这项迁移重写；读取商家配送配置要检查读取路径，创建或修改商家 profile 要检查写入路径。兼有两种行为的应用分别处理，不能把所有 deliveryProfile 操作都视为失效。

Carrier Service 注册与商家配送配置也是不同问题。原有 Shopify API 2026-10 迁移清单见来源，两条时间线不能混成一次 API 版本升级；同名费率显示变化也不能单靠更换 API 版本判断是否处理完成。

开放资格：10月2日的核对快照仍需按店铺确认

以下保留10月2日的公开资料核对结果，不把它冒充10月14日重新刷新后的资格说明。10月1日官方配送博客当时称所有商家均可选择加入；Shipping options by market 帮助页仍写 early access、仅部分店铺可用且逐步推出，未升级店铺继续使用 shipping profiles。博客措辞不能证明每家店都已有入口或已经升级。

8月24日企业官方介绍把10月1日写为新商家与符合条件的现有商家可开始选择加入的时间，2027年7月1日为所有商家转入新模式的目标。这个完整模式迁移目标，与论坛所说同名费率旧行为保留至2027年7月是不同表述；后者未提供准确截止日、时刻或时区，不能自行补成同一天。

该次应用升级指南还提示：未兼容应用的新安装会有警告，已有商家在应用未升级时手动启用可能故障；Shopify 在确认应用兼容前不会自动迁移使用该应用的商家。下文 API 路径和开发店要求沿用该次核对的官方资料；目标日期可能调整，当前资格、批次和权限仍以获授权店铺的实际支持情况核对。

商家启用新模式前，分步核对入口与应用

第一步，在获授权的 Shopify admin 中确认店铺使用传统 shipping profiles，还是 Markets 下的 shipping options，记录升级或启用入口与应用兼容警告。没有入口时，按当前帮助中心与 Shopify 支持核对资格，不把博客总体措辞当成强制切换步骤。

第二步，让应用团队确认是否读取或修改商家 profile，并用 ShopFeatures.marketDrivenShipping 核对实际模式，检查相应读写路径。即使同名费率显示行为已变化，也不能由此推断该字段一定为真。

第三步，在受控范围比对商品、市场、地点、费用和代表性结账地址的结果；有兼容警告或费率异常时先停止扩大启用。本文提供核对方案，未登录商家后台、启用功能或完成账户结账实测。

读取费率：按用途选择 Feed 或 Markets API

应用是 sales channel 或可以成为 sales channel 时，既有官方指南推荐 Contextual Product Feeds。它按商品变体和市场给出配送选项估计，涵盖商家市场费率与应用自有费率，要求 read_product_listings。先确认实际需要的国家、地区、商品和费率数据是否都有覆盖。

不符合该资格或需要原始配置时，不要强行套用 Feed。直接读取商家配送配置，应以 ShopFeatures.marketDrivenShipping 判断模式：新模式读取 Market.delivery，旧模式继续读取 deliveryProfiles；Markets 读取路径需要 read_markets。

过渡期在两种模式下比对相同市场、商品、地点和费率。API 请求成功只能说明请求得到响应，不能单独证明顾客看到的结账选项完整、没有重复或金额正确。

写入费率：先评估应用自有 profile

既有官方指南推荐多数写入商家配送配置的应用改为管理应用自有 delivery profile。用 deliveryProfileCreate 创建，按实际商品与地点配置；只有确实覆盖全部商品时才评估 coversAllItems。应用自有 profile 沿用原 API 和既有权限。

先并行比对旧路径与新 profile 的费率，再停止写商家 profile。隔离应用费率不等于可以忽略商家配置；尤其要核对实际结账中两种来源是否重复提供了同一项服务。

应用自有 profile 无法表达需求时，再评估 Markets API：ShopFeatures.marketDrivenShipping 为真时用 marketCreate 或 marketUpdate，旧模式仍写原商家 profile；Markets 路径需要 read_markets 与 write_markets。

先复核权限、市场和费率归属，在两种店铺模式下分别验证，避免把某一市场的设置覆盖到其他市场。

在开发店验证后，再提交兼容声明

前提是有可用的开发店和应用测试版本。既有官方说明要求在新建 development store 时选择 Market-driven shipping feature preview，不能给已有店追加该 preview。旧模式另准备受控测试店，按应用的实际读路径、写路径和结账地址设计夹具。

在新旧店分别记录 ShopFeatures.marketDrivenShipping、相关 Market 或 profile、权限、读取到的费率，以及代表性商品和地址的结账结果。核查应用自有费率与商家市场费率是否重复或丢失；这些是待执行的测试步骤，不是本文已经验证的账户结果。

应用升级并验证后，按 Shopify 指引提交 compatibility self-attestation，由 Shopify 标记兼容并清除商家警告。提交表单不能代替读写与结账回归，也不能证明具体商家已迁移。

异常时停止扩量，不假设店铺能自行回退

模式分支与店铺实际不符、权限不足、市场费率丢失或重复、结账结果异常时，停止扩大启用范围，保存店铺模式、请求 ID、市场、商品、地点与响应证据。不要靠重试同一旧请求或切换出口掩盖配置与权限错误。

尚未迁移的旧模式商家可暂时保留经验证的旧读写路径；已手动启用新模式的商家不能假设能自行回退店铺状态，应停止有风险的写入并按 Shopify 支持的路径处理。本文未验证任何商家的回滚权限、迁移结果或声明状态；IP 切换不能修复 API 模式、权限或运费配置。