优惠券系统，我等的是「叠加怎么办」

面电商产品经理，我常给一句很像需求的原话：运营要做「满 300 减 50，大促当天生效，可以跟品类券一起用」，两周内上线，之后每个月还要加两三种新玩法。

不少人听到就开始画表：coupon_id、user_id、amount、status。画得挺完整，但我等的那句话一直没出现——两张券叠加的时候，谁先算、门槛按哪个价算、退款退多少。

优惠券在面试里被当成一张表，在真实系统里是一套计价规则。差别就在这几个追问上。

本系列第 3/10 篇 · 上一篇：加购到支付，漏掉的不只是用户 · 下一篇：搜出三万件商品，排序听谁的

先把「券」拆成四种对象

我要求候选人至少分出四层：券模板（规则定义）、批次（发放预算与时间窗）、券实例（用户手里的那一张）、核销记录（用在哪一单、抵了多少）。

分层的意义不是数据库好看，是回答运营每天都在问的问题。改规则时已发出去的券变不变，答案是改模板要新开版本、老实例继续指向旧版本；一个批次超发了能不能追回，答案是预算和库存挂在批次上；用户投诉「我明明有券」但订单没抵扣，得能顺着实例和核销记录查到是哪一步被筛掉。

作用域也要在这一层说清楚：平台券、店铺券、品类券、单品券，能不能跨店凑单，运费和税费算不算进门槛。这些都是规则的字段，不是运营在后台随便填的一段备注。

还有一个常被漏掉的对象：资格。谁可领、限领几张、新老客、渠道来源、是否需要实名。资格判定放在领取时还是核销时，会直接决定黄牛能不能批量囤券。我一般会追一句：一个人用三个账号各领一张，你怎么防。这时讨论才会从「发券」走到风控。

叠加规则才是这道题的正题

单张券谁都会算。真正决定系统复杂度的是叠加。

规则集（题设示例）
  R1 平台满减：订单实付满 300 减 50，与店铺券可叠加，与平台券互斥
  R2 品类券：指定品类商品金额满 200 减 30，可与平台满减叠加
  R3 新客券：无门槛减 15，与任何券互斥
  计价顺序：先算作用域内的商品小计 → 应用店铺/品类券 → 重算门槛 → 应用平台券 → 分摊到行项目

这段配置里，每一条都能问出东西。

门槛按什么价算。用户买了 320 元的商品，先用了品类券减 30，平台满减的「满 300」还成不成立？两种口径都见过，但必须在产品规则里写死，并且让前台文案和结算页一致。我见过最糟的实现是前台按原价展示「已满足」，结算按优惠后金额判定「不满足」，用户看到的是一张明明有却用不了的券。

计算顺序决定谁出钱。店铺券先减，平台券的门槛可能被压到不满足；平台券先减，店铺承担的比例又变了。顺序不是技术细节，它决定了补贴成本在平台和商家之间怎么分，写错了会直接变成财务问题。

优惠分摊是分水岭。一单三件商品共减 80，每件各摊多少？这不只是展示：用户退其中一件，退多少钱；开票金额按哪个数；商家佣金按实付还是按原价抽；跨店订单平台补贴归到哪家店。我听到候选人主动说「优惠要按行项目分摊，退款按分摊后的实付退」，就知道他大概处理过售后工单。

互斥与优先级也要有确定解。两张券都可用时，是系统自动选最优、让用户手选、还是按优先级强制？自动选最优听起来友好，但会和用户「想把这张留着下次用」的意愿冲突，也让运营无法预测券的核销节奏。我的偏好是默认推荐最优但允许切换，并把「用户手动改选」记进日志——这个行为本身是很有用的偏好信号。

资损是护栏，别等事后对账

优惠券系统出事，通常不是算错几毛钱，是叠加出了规则外的组合，被批量薅走。

我期待候选人至少提到四类护栏：

• 预算护栏：批次总额和总张数上限，接近阈值自动降速或停发，运营能看到实时消耗；
• 价格护栏：券后价低于阈值时拦截，避免与限时价、秒杀价、员工价叠成负价或骨折价；
• 领取护栏：限领、频控、设备与账号维度去重，新客券要有新客判定的统一口径；
• 回滚护栏：规则配错已经发出的券怎么办，能不能批量冻结、作废、或按原规则履约。

第四条最能看出成熟度。规则一定会被配错，尤其是大促前临时加玩法的时候。上线前要问的不是「怎么保证不配错」，而是「配错之后十分钟能不能止血」。我会要求给出具体动作：按批次冻结、关闭入口、保留已核销订单、公告口径、审计日志能追到是谁在什么时候改了哪个字段。

价保也在这里冒出来。用户刚买完就降价、或者后来发了一张更大力度的券，要不要补差。这不是客服政策，是促销规则的一部分，得在活动配置时就决定，否则大促后一周会被集中投诉。

每加一种券就改一次代码，两周排期撑不过三个月

最后一问我会把话题拉回排期：运营下个月还要上「满件打折」「第二件半价」「跨店每满 200 减 30」，你怎么接。

把规则写成 if 分支是最快也最贵的做法。三种券是三个分支，十种券加各种叠加组合就是一团没人敢碰的代码，每次上线都要全量回归。产品经理在这里要给的不是一个规则引擎的架构图，而是运营能自己配置到什么程度的边界。

我的习惯是把「可配置」和「需研发」划一条线：门槛、金额、时间、人群、作用域、叠加关系、优先级进配置；新的优惠形态（按比例、按件数、阶梯递减）需要研发加一种计算类型，但只加一次，之后同类型都能配。配置要有预览和试算：填完规则，输入几组典型订单，立刻看到每一步的计价结果和分摊明细。这个试算页面比任何需求文档都能减少事故。

灰度也别省。新规则先对内部账号生效，再放小比例流量，观察核销率、客单价、券后价分布和异常拦截量，最后才全量。生效时间要写清时区，大促的活动切换按秒计，「零点生效」到底是服务器时间还是用户本地时间，写错了就是一批客诉。

这道题我听什么

及格线是能画出模板、批次、实例、核销四层，说清领取与核销的状态流转。

好一档会主动谈叠加：计价顺序、门槛重算、互斥优先级，以及优惠分摊怎么影响退款和开票。

再加分的，是能把话题带到资损和运营效率上——配错了十分钟怎么止血、下个月的新玩法要不要改代码、活动结束后哪些数据留下来供复盘。这些都不在「设计一张优惠券表」的字面要求里，但恰恰是电商 PM 日常真正在处理的事。

我最后常问一句：这套东西上线后，你每天早上第一眼看哪个数。答「核销率」的算称职；答「先看异常拦截量和最低券后价，再看核销率」的，多半被薅过。