Shopify Scripts 将于 2026 年 6 月 30 日停止执行,您在脚本编辑器中构建的每个自定义折扣、配送或支付规则都将在该日期停止适用。替代品是 Shopify Functions,它在结账内的服务器端运行您的逻辑。有三种方式可以实现:聘请开发者编写 Function、向代理商支付费用或在无代码 Functions 应用中重建基于规则的折扣逻辑。紧迫的部分是失败是静默的。停止触发的脚本或不匹配购物车的迁移规则不会抛出错误,也不会通知您。它只是安静地收取全额价格,直到客户抱怨。
本指南解释了脚本的作用、为什么 Shopify 要弃用它们、Function 实际上是什么、为什么迁移我的脚本实际上是多达三个独立的迁移、静默失败的陷阱以及如何绕过它、无代码应用可以覆盖什么、什么不能覆盖,以及何时您仍然需要开发者的诚实分解。
Shopify Scripts 发生了什么,以及何时?
Shopify Scripts 正在被弃用。根据Shopify 开发者文档,Shopify Scripts 将于 2026 年 6 月 30 日停用。所有现有的 Shopify Scripts 将在此日期后停止运行。有两个重要日期,第一个已经过去:
- 2026 年 4 月 15 日: 编辑和发布新的 Shopify Scripts 不再可能。根据Shopify 开发者变更日志,在此日期后,您完全无法创建或更改脚本。
- 2026 年 6 月 30 日: 所有 Shopify Scripts 完全停止执行。脚本中的任何折扣、配送或支付逻辑都将停止运行。
如果您的商店在 2026 年 7 月 1 日仍然依赖脚本,该逻辑已经在您阅读本文时离线。自定义没有出错或回退到安全默认值。它们陷入了沉寂。这是关于此截止日期最重要的一点:这不是您会从仪表板警告中注意到的响亮失败。这是一个缺失。
Shopify 还提供了一个工具来帮助您确定范围。Shopify Scripts 自定义报告 帮助您识别哪些当前自定义可以转换为 Function 或公共应用。如果您还没有运行它,那就是第一步。
图像占位符 (图像 1): Scripts 停用时间线
建议的视觉效果: 在白色背景上的干净 16:9 水平时间线,有三个紫色和深金色的里程碑标记。标记一,2026 年 4 月 15 日 - 编辑结束用金色表示。标记二,2026 年 6 月 30 日 - Scripts 停止执行用紫色表示,带有一个小红色静默标签。标记为 Shopify Functions 的尾随箭头在最后一个标记之后继续。扁平、最小化、无衬线标签,无摄影。
Shopify Scripts 做了什么,为什么 Shopify 要弃用它们?
Shopify Scripts 是在脚本编辑器应用中运行的小型 Ruby 程序,可自定义购买流程的三个部分: 购物车和行项目折扣、配送费率和支付方式。Shopify Plus 上的商户可以编写一个脚本,提供分级折扣、隐藏某些地址的配送选项或重新排列结账时的支付方法。脚本之所以强大,正是因为它们是任意代码: 如果您可以用 Ruby 表达它,您就可以做到。
Shopify 用 Shopify Functions 替代它们。根据迁移文档,通过 Shopify Functions,这些自定义现在通过专用 Function API 处理,提供更好的性能和灵活性。Function 在结账管道内的 Shopify 自己的基础设施中运行,这使它们比旧的脚本模型更快、更可扩展,这意味着相同的逻辑是否适用于购物车页面、结账页面或加速钱包(如 Shop Pay)都是相同的。
权衡是 Function 不是您粘贴 Ruby 的文本框。它们是开发者工件: 您使用 Shopify CLI 搭建它们,用 Rust 或 JavaScript 编写逻辑,定义 GraphQL 输入查询,并通过应用部署它们。这种转变,从商户编写脚本到开发者交付 Function,是整个迁移项目而不是复选框的原因。
什么是 Shopify Functions,为什么它们通常需要开发者?
Shopify Functions 让您用在结账期间运行的自定义代码扩展或替换 Shopify 后端逻辑的部分。有专用的 Function API 用于脚本过去做的事情,包括折扣 Function API、交付 (配送) 自定义 API 和支付自定义 API。
Function 的两个属性对您的迁移计划很重要。
Function 在服务器端运行,一次
Function 在 Shopify 结账内运行,而不是在您的主题中。这是对计算购物车页面上主题 JavaScript 中的总数然后与结账收费不一致的折扣方法的真正升级。因为 Function 是单一的真实来源,购物车预览和最终费用是相同的计算。这也是为什么正确构建的 Function 在完全跳过购物车页面的 Shop Pay、Apple Pay 和 Google Pay 中完全相同地适用。
Function 默认是构建的,而不是配置的
从头开始编写 Function 是一个开发者任务。您需要 Shopify CLI、语言工具链和对 Function 的输入查询和结果形状的熟悉。关于计划可用性有一个细微之处值得了解: 根据 Shopify 的Function 可用性文档,任何套餐上的商店都可以使用通过 Shopify 应用商店分发并包含 Function 的公共应用。只有 Shopify Plus 套餐上的商店才能使用包含 Shopify Function API 的自定义应用。简单来说: 应用商店的公共应用可以为任何套餐带来 Function,但定制构建的 Function 是仅 Plus 的路径。这种区别是使无代码 Function 应用对不在 Plus 上但过去依赖开发者的商家很有吸引力的原因。
好消息是,一旦在应用中部署了 Function,商户可以从管理面板配置它,而无需接触代码。当 Function 启动时,Shopify 说,商户最终用户在修改其自定义时永远不必接触一行代码。代码编写一次; 设置在管理面板中。
为什么迁移我的脚本实际上是三个独立的迁移?
这是让人惊讶的细节,它直接来自商户如何在 Shopify 社区论坛上描述工作的方式。单个脚本文件可以同时处理折扣、配送和支付逻辑。Function 刻意将其分为独立的、独立的 Function 类型。
- 折扣逻辑 (分级定价、BOGO、订单和产品折扣、堆叠规则) 映射到折扣 Function API。Shopify 统一的折扣 Function API 可以从单个 Function 中对所有三个折扣类别 (产品、订单和配送) 应用节省。
- 配送和交付逻辑 (重命名、重新排列或隐藏交付选项) 映射到交付自定义 Function API,一个完全独立的 Function。
- 支付逻辑 (重命名、重新排列或隐藏支付方式) 映射到支付自定义 Function API,第三个独立的 Function。
所以句子我需要迁移我的脚本通常意味着迁移多达三个不同的东西,分别配置和部署。无代码折扣应用可以重建第一个桶。它不到达配送和支付桶,这正是为什么您必须在假设任何单个工具覆盖它之前清点您的旧脚本。首先按层面分类工作,然后为每个层面选择一条路径。
图像占位符 (图像 2): 一个脚本变成三个 Function
建议的视觉效果: 16:9 图表。左边,单个标记框一个 Shopify Script (Ruby)在板岩。三个箭头向右扇向三个单独的框: 紫色的折扣 Function、金色的交付 Function、蓝板色的支付 Function,每个都带有一个小的独立部署标题。干净的扁平向量,品牌颜色紫色和金色,无摄影。
静默失败的危险,以及如何测试它
这是让商家损失真金白银的部分,它值得自己的部分,因为它既适用于截止日期本身,也适用于您重建的每条规则。
Shopify Function 要么格式良好并正在运行,要么配置错误且沉默。没有可见的中间状态。条件不匹配给定购物车的 Function 不会触发、不会出错,也不会向您发出警告。这是设计意图: 您从正确运行的 Function 得到的相同沉默 (它对不应该符合条件的购物车正确地什么都不做) 是您从损坏的 Function 得到的沉默 (阈值中的打字错误、范围到错误集合的规则、从不触发的层)。
通过这次迁移工作的商家在 Shopify 社区论坛上描述了相同的经历: 一条规则悄悄停止应用折扣,商家只会因为客户抱怨被收取全额价格而发现。没有错误、没有警告、订单日志中没有任何东西。商店在损坏的设置上运行了数周,没有人注意到。
唯一可靠的防御是在信任规则上线之前双向测试:
- 构建应该触发的购物车。 组装一个满足规则所有条件的真实购物车,下单,并逐行阅读结账摘要。确认您期望的确切折扣存在,金额符合您的期望。
- 构建不应该触发的购物车。 组装一个故意不符合条件的购物车,例如一个项目低于您的数量阈值,并确认折扣正确地保持关闭。
不应该触发时触发的 Function 与从不触发的 Function 一样昂贵。您没有测试完成,直到您看到规则应用和正确拒绝。也通过 Shop Pay 运行应该触发的购物车,以确认加速路径同意标准结账。
您在这里时的另一个保存步骤: 现在保留您的旧脚本源。脚本编辑器完全停用后,其存储的代码从 Shopify 变得无法恢复。现在导出或复制您的脚本源,即使您还没有准备好重建它,这样您就能引用任何替代它的东西。
无代码应用可以迁移我的脚本吗? 它覆盖什么和不覆盖什么
特别是对于折扣层,无代码 Function 应用可以吸收商家过去用脚本做的大部分东西。如果您的脚本逻辑归结为规则,即当购物车看起来像 X 时,应用折扣 Y,基于配置的应用通常可以无需开发者重建它。这涵盖了大量共同的地方:
- 分级和数量折扣,如购买 3 个或更多,节省 15%。
- 购买 X 获得 Y 和 BOGO 逻辑,包括重复层,如购买 6 个获得 2 个,购买 9 个获得 3 个。
- 报价之间的显式堆叠和组合规则。
- 计划的开始、结束和即时暂停一个活动。
无代码折扣应用不能做什么也同样重要,要明确说出来,因为假设反面是迁移无声失败的方式:
- 任意自定义代码。 如果您的脚本运行特定的定价公式或任何生成器公开的规则不能减少的一次性条件,没有折扣应用可以表达它。该逻辑仍然需要开发者编写自定义 Function。
- 配送和支付自定义。 这些是独立的 Function 类型 (交付和支付)。仅折扣应用不会到达它们。开发者独立迁移这些。
- 规则基折扣配置之外的任何东西。 如果它不是从根本上条件进入,折扣出来,配置屏幕是错误的形状。
诚实的测试很简单: 写下,在一句话中,您的旧脚本的每一部分做了什么。如果句子是关于折扣的规则,无代码应用是一个强有力的候选者。如果它是一个公式、配送变化、支付变化或您无法用规则表达的东西,为那一部分的开发者预算。
用 Stackable 可靠地运行这个迁移
如果您的脚本的折扣逻辑基于规则、分级、BOGO、堆叠和排期,Stackable 在本机 Shopify Functions 上重建确切的层面,无代码,并且对其边界诚实。
- 它重建基于规则的折扣逻辑,包括数量和分级定价、BOGO、显式折扣堆叠、和计划的开始、结束和暂停,作为您在管理面板中编辑而不是维护的 Ruby 的配置。
- 数学在 Shopify Function 内部运行,因此购物车、结账和 Shop Pay 计算一个相同的总数。没有主题与结账漂移,这是旧折扣设置的常见失败模式。
- 购物车模拟器让您在上线前运行应该触发和不应该触发的购物车,因此您在预览中捕捉静默配置错误,而不是在客户投诉中。
- 它对范围诚实。Stackable 不运行任意自定义代码,也不接触配送 (交付) 或支付自定义。真正特定的逻辑和这两个独立的 Function 类型仍然需要开发者。
免费安装 Stackable,趁还没悄悄丢单,把基于规则的折扣逻辑迁到 Shopify Functions 上重建。usestackable.com/pricing 🚀
工作示例: 您今天可以遵循的迁移检查清单
使用此序列将我的脚本中断变成受控迁移。表格将典型的多用途脚本映射到其目标。
然后按顺序完成步骤:
1. 在构建任何东西之前清点旧脚本
趁脚本编辑器仍然可用时打开它,并为每个行为写一句话。运行 Shopify 的脚本自定义报告以确认没有隐藏任何东西。导出 Ruby 源并将其存储在安全的地方,因为一旦编辑器停用,它就变得无法恢复。
2. 按层面分割清单
将每个行为分类为折扣、配送或支付。这立即告诉您无代码折扣应用可以处理哪些部分,哪些部分需要开发者。不要假设一个工具涵盖所有三个。
3. 无代码重建基于规则的折扣部分
对于每个归结为条件进入、折扣出来的行为,在本机 Shopify 折扣或基于 Function 的折扣应用中重新创建它。如果要约是旨在堆叠,显式设置组合规则。
4. 将非规则部分交给开发者
定制公式、交付自定义和支付自定义转到开发者或代理商作为他们自己的 Function 构建。将导出的脚本源作为规范提供给他们。
5. 双向测试每条重建的规则
对于每条规则,运行应该触发的购物车和不应该触发的购物车。逐行阅读结账摘要。规则直到您看到它应用和正确拒绝时才算迁移。
6. 验证加速结账
通过 Shop Pay 运行您应该触发的购物车。因为 Function 在服务器端计算,正确构建的规则完全相同地应用。这是您最后一次检查,确保没有东西依赖于钱包跳过的主题代码。
图像占位符 (图像 3): 在信任之前双向测试
建议的视觉效果: 16:9 拆分图。左面板标记为应该触发的购物车显示结账摘要,正确存在绿色折扣行。右面板标记为不应该触发的购物车显示结账摘要,折扣正确缺失,绿色勾选标记。中心标题读静默规则从不出错 - 双向测试。品牌颜色紫色和金色,扁平向量,无摄影。
总结
- Shopify Scripts 将于 2026 年 6 月 30 日停止执行,编辑已于 2026 年 4 月 15 日停止。任何仍在使用的脚本现在已离线。
- 失败是静默的。停止的脚本或不匹配购物车的迁移规则从不出错,也不向您发出警告。它只是收取全额价格。
- Function 是替代品,在结账内的服务器端运行,但从头开始编写是开发者任务,自定义 Function 是仅 Plus 的路径。
- 一个脚本通常变成三个迁移: 折扣、交付和支付 Function,每个都独立部署。
- 无代码 Function 应用可以重建基于规则的折扣逻辑 (分级、BOGO、堆叠、排期)。它不能做任意代码、配送或支付自定义。
- 现在保留您的旧脚本源。一旦脚本编辑器停用,它将变得无法恢复。
- 使用应该触发和不应该触发的购物车测试每条重建的规则,并逐行阅读结账摘要,包括通过 Shop Pay。
相关文章
- 从 Shopify Scripts 迁移: 完整的救援路径、什么在无代码中重建、什么仍然需要开发者。
- Shopify 中的折扣堆叠如何工作: 为什么本机仅应用最高折扣,以及如何正确组合要约。
- 数量折扣和数量分界: 重建对相同产品进行计数的分级定价,而不是整个集合。
- 折扣堆叠,正确完成: 三个类别每层组合开关,带有现场购物车模拟器。
- Shopify 在购买 X 获得 Y 上的 100 产品限制: 迁移后在整个目录中运行 3 换 2。
- Stackable 定价: 计划、免费层和每个包含的内容。


