一套即使在黑色星期五也稳得住的折扣引擎，而不只是在三月的某个普通周二
大多数折扣类应用在日常流量下都运行正常，问题恰恰出现在流量高峰期，那正是各种“取巧做法”暴露的时候。本页将说明折扣类应用为何会在 BFCM 期间失效、一份在流量高峰期运行折扣活动的简短行动手册，以及 Stackable 具体承诺了什么，用可验证的方式说明，而不是一个谁也无法核实的正常运行时间数字。
免费安装折扣类应用的公开评价中，每年 BFCM 季都会反复出现同一种失效模式：
“这个应用在黑色星期五直接崩了。全年都运行正常，却偏偏在我们流量最大的那一天莫名其妙地出问题，等我们发现时已经损失了好几千美元。”
两个偷工减料之处能解释大部分问题
这种模式背后，主要是两种取巧做法在作祟：
客户端价格取巧
有些应用在浏览器端计算折扣，用 JavaScript 改写页面上显示的价格。购物车里看起来没问题，但结账时的实际总价是由 Shopify 结账系统单独计算的，而不是这个应用。一旦遇到流量高峰、网络较慢，或客户使用了广告拦截插件，这段 JavaScript 就可能悄悄失效，而页面上显示的折扣价格却依然保留。客户看到的是一个数字，结账时扣的却是另一个。
草稿订单结账
另一些应用会把购物车转成草稿订单来应用自定义价格，这是 Shopify Functions 出现之前的一种变通做法。草稿订单不在正常的结账流程之内，会导致原生折扣码和订单分析失效，还多了一个环节，恰恰可能在流量骤增时出问题。
一份简短的 BFCM 清单
在流量高峰到来前提前排好活动日程
在 BFCM 周之前设定好精确的开始和结束时间，这样就不需要有人一边盯着流量看板，一边手动上线活动。
先用模拟器跑一遍示例购物车
在活动正式上线前，先用一个示例购物车进行测试，确认合计金额与预期完全一致，这正是结账时会执行的同一套计算逻辑。
清楚一旦出现异常，可以立即暂停
如果活动上线后表现异常，只需点击一下即可暂停，且会立即在整个店面生效，而不仅仅作用于新加载的页面。
可验证的具体承诺，而非一个正常运行时间数字
比起发布一个我们尚无法完全兑现的数字，我们更愿意承诺你可以在自己店铺中亲自验证的事情。
常见问题
在 BFCM 级别的流量下，Stackable 究竟有什么不同？
无论流量大小，折扣计算都运行在同一套 Shopify Function 基础设施之上，不存在另一种在高负载下表现不同的“高峰模式”或客户端回退方案。不管是平常的周二，还是全年流量最高的那一小时，运行的都是同一套服务器端计算逻辑。
我能把活动设定为在黑色星期五零点整准时开始吗？
可以。在创建活动时设定好开始和结束的日期与时间，活动会按计划自动上线和下线，不需要任何人在那一刻在线操作。
如果我需要在 BFCM 期间中途停止活动，多快能生效？
在后台点击一下即可暂停正在进行的活动，改动会在60秒内在整个店面生效。
你们会公布正常运行时间数字吗？
目前还没有，我们也不希望公布一个缺乏历史数据支撑的数字。我们现在能够承诺的，是架构层面的保证：服务器端计算、购物车与所有结账场景下总价完全一致，以及快速且可验证的暂停机制。