2026年8月13日
Shopify Checkout Extensibility 迁移：先盘点旧定制，再分批替换
先说结论
Checkout 迁移不是换一个模板文件。旧 checkout.liquid、Shopify Scripts、感谢页脚本和第三方追踪各有不同替代路径，必须先盘点功能与数据，再在副本环境逐项验证。
不少 Shopify Plus 商店的结账定制，是几年里一点点叠出来的：运费提示写在 checkout.liquid，折扣逻辑放在 Scripts，转化代码贴在感谢页，售后推荐又由应用接管。迁移时如果只问“页面长得像不像”，最容易漏掉的是价格逻辑、事件和异常流程。
先把旧能力按类型拆开
| 旧做法 | 要确认的业务 | 新路径 |
|---|---|---|
| checkout.liquid | 字段、提示、布局、品牌样式 | Checkout UI Extensions、Checkout Branding API |
| Shopify Scripts | 折扣、运费、支付方式逻辑 | Shopify Functions 与兼容应用 |
| 感谢页附加脚本 | 广告归因、问卷、二次推荐 | Pixels、Web Pixels API、结账扩展 |
| 硬编码第三方组件 | 风控、会员、客服与数据回传 | Checkout apps 或服务端集成 |
Shopify 已经停止 checkout.liquid 在结账核心步骤中的使用，感谢页与订单状态页也进入新的扩展体系。Shopify Scripts 的支持期限也已经结束。迁移项目现在应被视为稳定性与维护项目，而不是可无限延期的视觉升级。
迁移验收不能只走一笔订单
- 普通商品、订阅、预售、礼品卡与缺货场景分别测试。
- 折扣码、自动折扣、阶梯价格和免邮条件不互相冲突。
- 不同市场、币种、税费和配送方式显示符合预期。
- 支付失败、地址修改、订单取消与退款事件能够回传。
- 感谢页、订单状态页和客户账户中的后续动作仍可使用。
建议分三批迁移
- 先迁基础与品牌。 颜色、Logo、字体、必需提示和基础追踪先稳定。
- 再迁交易逻辑。 折扣、配送、支付和 B2B 条件逐项对照旧订单。
- 最后迁增值体验。 加购、问卷、推荐和会员提示，在不影响结账完成的前提下加入。
上线前保留回退清单
记录每个扩展的负责人、版本、配置入口和停用方式。结账问题发生时，团队必须能在几分钟内判断是平台、支付、扩展还是业务规则导致。
迁移后还要观察数据
至少对比结账开始率、支付失败率、折扣使用、配送方式分布和 purchase 事件。若数据变化，先排查定义和事件是否改变，不要立即把所有波动归因于新结账体验。
日本語 
简体中文 
English 
香港中文 
Deutsch 
繁體中文