跳至主要内容
策略

Shopify 上「按结账」vs「按客户」的限制:为什么大多数应用挡不住黄牛

Jahangir Alam2026年5月12日2026年9月26日 更新16 min read
order 1order 2order 32 of 2 per customer this month

Shopify 自带的数量限制每开一次新结账就会重置一遍。一笔订单刚刚下到上限,完成支付,再开一笔——计数器又回到零。对限量发售来说,这是 Shopify 订单管理里最大的一道口子。黄牛知道,机器人也知道。商家通常都是付了惨痛代价才搞清楚——基本都是在一次发售被同样的三个人五分钟扫光之后。

OrderRules 按客户 vs 按结账对比——把"每位客户 1 件"跨所有订单一致执行,真实客户表格里同时展示了被允许的和被拦下的尝试,包含典型黄牛模式

本文讲清楚"按结账"在实际中到底意味着什么,Shopify 自带的限制为什么会这样工作,在订单限制类应用里哪些真正在做"按客户"的规则,以及跨订单追踪在真实场景里是怎么跑起来的。

如果你已经明确知道自己需要的是按客户的限制,只想看配置步骤?可以直接跳到 按客户的订单限制指南 看走查。本文是那篇之前的概念解释。

问题所在:Shopify 原生限制每次结账都会重置

Shopify 允许你给每个商品设置一个购买限制——比如"每单最多 2 件"。这条规则挂在商品或变体上,在购物车被组装时校验。只要一笔结账里这件商品的数量不超过 2,订单就放行。订单完成之后,客户可以再开一次结账,这件商品照样允许"每单 2 件",于是他再买 2 件。

跨结账之间没有任何内置的聚合。Shopify 的结账层能看到当前的购物车、当前的客户(如果登录了)、以及购物车里的商品。默认情况下,它看不到"过去 30 天这位客户总共买过多少件这个商品"。那种信息存在订单表里——Shopify 在做结账校验时并不会去查订单表。

这不是 bug。Shopify 这条原生限制本来就是为库存保护和大单安全设计的:防止购物车一次性接受 10000 件。它从来就不是为了反黄牛而设计。

"按结账"在实战中长什么样——一份黄牛操作手册

如果你在 Shopify 上做限量发售,只用"每单 2 件"的原生限制,黄牛会这样操作:

  • 9:59 — 公告 10:00 开抢
  • 10:00:00 — 打开商品页,加 2 件入购物车,结账,支付
  • 10:00:45 — 同一个浏览器,再打开商品页,加 2 件,结账,支付
  • 10:01:30 — 第三次结账,流程一样
  • 10:02:15 — 第四次结账
  • 10:03:00 — 第五次结账

三分钟之内,一个人就买走了本来号称"每位客户 2 件"的发售里的 10 件。同一个 Shopify 客户账号、同一个邮箱、同一个收货地址、同一张信用卡。原生限制每一次都正确触发了——然后五笔全部放行。等真正的粉丝在 10:05 刷新页面时,发售已经卖光。

球鞋发售、街头潮牌新品、收藏品发售相关的社区帖,把这个剧本反反复复演给你看。商家的吐槽都很一致:*"我设的是每位客户 2 件,为什么有人买了 10 件?"*答案就是:规则说的是"每单 2 件",不是"每位客户 2 件"。

"按客户"是什么意思——跨订单追踪

"按客户"的限制限制的是 同一个购买者在所配置时段里、跨所有订单的累计购买总量。规则不再是"每单 2 件",而是"每位客户每场发售 2 件"、"每位客户终身 2 件"或者"每位客户每周 1 件"。

要做到这一点,应用必须做三件 Shopify 原生限制不会做的事:

  1. 识别同一个客户,即便他分了多次结账
  2. 维护一本账,记录在所配置时段里,每位客户已经买了多少件
  3. 在每次结账时对账校验——必须在服务器端,这样从直链 checkout URL 进来也绕不过去

这就是"按结账"应用和"按客户"应用在架构上的根本差别。同时这也解释了为什么大多数订单限制类应用都还停留在"按结账"上:它们只是接在 Shopify 自带的按商品校验上,从来没维护过任何客户账本。

Shopify 上哪些应用是"按结账",哪些是"按客户"

在主流的 Shopify 订单限制类应用里,真正在结账层强制执行"按客户"限制的只有很小一部分。具体分类:

应用是否真的按客户强制执行备注
OrderRules是——通过 Shopify Functions 在结账时强制以 Shopify Customer ID 为准。要求登录;客户限制开启期间拦截游客结账。
DC Customer Order Limits是——在结账时强制支持终身上限和 Shopify Flow 集成;Pro 方案 $14/mo。
KOR Order Limits仅支持按标签(Pro 方案)需要人工给客户打标签——比基于账本的追踪更弱。
Avada Order Limits否——只有按结账装机量最大,但不跨订单追踪。
MinMaxify否——只有按结账按商品的最小/最大数量——和原生一样的缺口。
MinCart否——只有按结账购物车级规则,没有客户账本。
Pareto Order Limits否——只有按结账免费方案,基本的按商品规则。
LIMITER (MageComp)否——只有按结账按年收费,仅有 4 条评价。

完整 8 款应用的评分、价格和场景推荐,见 Shopify 订单限制应用合集页。两款真正在按客户层面执行的应用之间的对比,见 OrderRules vs DC Customer Order Limits。

还有一类只为单一目的而生的小众应用——Limit Once(Wandelic)和 UR: Limit 1 Item Per Customer(UnReact)——只覆盖一种按客户的规则,而且只覆盖那一种。它们能撑住一场发售、一个商品、一条规则,稍微复杂一点就是死胡同。

识别"按客户"规则的三种身份信号

当一个应用说自己执行按客户限制时,下一个要问的问题是:*它是怎么认出这位客户的?*答案直接决定了这条规则有多难被绕过。

Shopify Customer ID——对已登录的客户来说,Customer ID 是最强的身份标识。清 Cookie、换浏览器、开无痕都伪造不掉它。客户一旦登录,就被唯一锁定,OrderRules 的账本就用这个 ID 来索引。

邮箱地址——对游客结账来说,一些应用会退而使用客户在结账时填的邮箱。如果一个黄牛接连用同一个邮箱开了好几次游客结账,就会被抓住。绕开的方法是每次换一个邮箱——而这件事对那种和黄牛对线的发售来说,简单到不能忽视。

收货地址——就算邮箱不一样,反复指向同一个收货地址的订单也是可以识别出来的,一些商家会事后排查这种模式("用 10 个假邮箱账号,但全部送货到黄牛的同一套公寓")。

OrderRules 走的是最严格的路线:客户限制要求登录,因此开启期间游客结账被拦截,每一笔计入的订单都与一个 Customer ID 绑定。对偏对抗的场景(球鞋发售、收藏品、被黄牛盯上的诱饵商品)来说,这才是正确选择——完整的威胁模型见 反黄牛操作手册。

游客结账为什么会击穿"按客户",以及怎么补

绝大多数"按客户限制没生效"的吐槽,根源都是游客结账被滥用。一个黄牛在每次游客结账里都换一个邮箱,在应用看来就像是每次来的都是不同的人——除非这个应用强制登录。

OrderRules 强制登录:客户限制开启期间,游客结账被拦截,客户必须登录。Customer ID 就成了唯一可信源。这是限量发售、独家系列等"黄牛套利就是首要威胁"的场景的正解。由于它是全店生效的,在一般零售店铺上要权衡它带来的结账摩擦。

DC Customer Order Limits 在它的 Pro 方案下提供类似的能力。其余只做"按结账"的应用在这件事上压根给不出答案——它们本身就不跨订单追踪,游客结账对它们来说根本不构成问题。

"按结账"什么时候其实没问题

并不是所有限制都得是按客户的。在一些场景里,按结账是合适的,按客户反而是杀鸡用牛刀:

  • 库存安全上限——"这个 SKU 单笔订单不超过 100 件",防止有人不小心一次买太多。按结账是对的——Shopify B2B 目录可以为公司买家设置按变体的最高数量。(OrderRules 的商品上限则不同:它是所有顾客在每天、每周或每月共享的总量。)
  • B2B 的整箱数量——"按 6 的倍数下单"或"每个 SKU 至少 12 件"。这种规则只关心订单形状,不关心客户历史,按结账完全够用。
  • 批发的最低订单金额——"购物车合计至少 $500"。这条规则盯的是购物车合计,不是哪个买家,按结账就合理。OrderRules 不设置购物车合计最低额;Shopify 的 Checkout Blocks 应用在所有套餐上都能处理订单金额限制,可面向所有客户或仅限 B2B。

判断的关键是:这条规则到底关心的是谁在买,还是买了什么。关心"谁",必须按客户。只关心"买了什么",按结账就够。

在 OrderRules 里配置真正的按客户限制

完整配置步骤见 按客户的订单限制指南,简版如下:

  1. 从 Shopify App Store 安装 OrderRules
  2. 进入 Customer Limits,新建一条规则
  3. 选择限制类型——按订单数、按总数量、或按消费总额
  4. 选择周期——日、周、月、年、滚动 30 天或终身
  5. 确认已要求登录——客户限制开启期间游客结账会被拦截
  6. 用一个客户账户测试——先下一笔贴着上限的订单,再尝试第二笔

执行通过 Shopify Functions 完成,所有结账都在服务器端被校验一遍。Shop Pay、Apple Pay、Google Pay 和直链 checkout URL 全都过同一道校验,客户端无法绕过。关于 Shopify Functions 的 Checkout Validation 是怎么跑的更技术性的细节,可见 OrderRules 如何使用 checkout validation 函数。

总的来说

如果你的痛点是"我设的是每单 2 件,可有人买走了 10 件",那不是限制失效了——是你本该上的是"按客户"的规则,却装了一条"按结账"的规则。Shopify 原生的限制就是按结账;市面上大多数订单限制应用也都是按结账;真正在结账层做按客户的,只有 OrderRules 和 DC Customer Order Limits。

对限量发售、反黄牛搭建、独家上新,以及任何"公平分配"本身就是品牌承诺一部分的商品来说,"按客户"才是和商家意图一致的规则。对其他场景——库存上限、B2B 整箱、购物车最低额——按结账完全够用。

想看 8 款应用一一对比?去看 Shopify 订单限制应用合集页。两款真正能做按客户结账校验的应用之间的专项对比,见 OrderRules vs DC Customer Order Limits。要了解把按客户限制当作一层防御的完整反黄牛思路,见 反黄牛指南。

常见问题

「按结账」的限制只针对一次订单——这一单完成之后,客户可以开一个新的结账,再次到达同样的上限。「按客户」的限制会跨多个订单追踪同一人,把总数限制住。Shopify 自带的数量限制是「按结账」的。各应用做法不同:OrderRules 和 DC Customer Order Limits 通过 Shopify Functions 在结账层强制执行真正的「按客户」限制;Avada、MinMaxify、MinCart、Pareto 和 LIMITER 都只是按结账;KOR 提供按标签的限制(更弱,需要 Pro)。

Shopify 会针对挂在每个商品或变体上的规则去校验购物车和结账,但它在结账层并没有内置任何按客户的购买历史聚合。订单一旦完成,下一次结账就从零开始。原生层面没有「这位客户本月已经买过 N 件」这样的判断。要做到这一点,必须有一个应用维护自己的客户账本,并在服务器端用它来校验。

能。如果你设的是「按结账」2 件上限,一个黄牛会先下一笔 2 件的订单,马上再下一笔,然后再一笔。五分钟下五单。同一个邮箱、同一个收货地址、同一个人。从技术上看,每次限制都「执行」了。可发售已经被买空。来自限量发售商家的社区帖一次又一次地记录了完全一样的场景。

只有 OrderRules 和 DC Customer Order Limits 通过 Shopify Functions 在结账层强制执行真正的「按客户」限制。KOR 在 Pro 方案中提供按标签的限制(需要人工给客户打标签——是一种较弱的形式)。Avada、MinMaxify、MinCart、Pareto 和 LIMITER 全都只是按结账。像 Limit Once(Wandelic)和 UR: Limit 1 Item Per Customer(UnReact)这样的小众应用,处理的是一种按客户的规则,但没有其他类型。

通过 Shopify Customer ID。按客户限制要求买家登录,因此客户限制开启期间 OrderRules 会拦截游客结账——Customer ID 是唯一可信源,清 Cookie 或换邮箱都伪造不掉。累计计数在每次结账校验时都在服务器端检查。

需要。OrderRules 按 Shopify 客户账户累计购买量,因此客户限制要求登录,并且在开启期间会拦截游客结账。这就堵住了经典的绕过路径——黄牛每次游客结账换一个邮箱——但它是全店生效的,所以最适合买家本来就预期要有账户的场景:限量发售、会员制店铺、B2B 和员工商店。

正在挑选应用?

查看 OrderRules 与该类别中其他所有 Shopify 应用的对比。

准备好掌控你的订单了吗?

免费试用 OrderRules