如果你整体设计过电商网站的促销功能，整理过相关的促销逻辑（例如，针对商品或订单的满减、满赠、折扣、优惠券等等），那么你一定清楚：如果对这些促销类型进行任意组合，将会有非常多样化的场景，这对于系统来说极易发生重叠甚至冲突的情况，那时你是如何处理这些逻辑关系的，又是如何做到在满足业务/运营需求的同时，最大化的降低系统判断逻辑的？如果你所设计的只是促销系统中的某个功能模块，会很容易陷入逻辑死循环，因为只有从整体上设计促销逻辑才能保证各子系统流程顺畅流转。笔者尝试脱离实际促销场景，抽象出一条行之有效的促销整体原则。
用一句话概括这条原则：同类型通过实体进行互斥、不同类型可以相互叠加。这里说明实体是商品或者订单。
为什么会有这么一句话？我们来看下下图：
电商系统订单金额计算流程
促销计算逻辑
上图展示了电商系统中，一笔订单导入系统后，它的价格是如何计算出来的。为什么要说这个呢？
电商所谓营销，归根结底都是订单金额的变化；如果我们清楚的知道订单金额的计算流程是怎样的，那么我们只需要顺着系统的计算流程做促销，就不用担心各种促销类型之间产生重叠或者冲突的情况了。
当我们知道这个关系后，就可以将营销活动区分为三种类型：改商品价格、改商品小计价格、改订单价格，因为无论什么营销归根结底都是可以描述成改价格。
第一种类型：修改商品价格
一笔订单被提交时，系统必然首先查找出订单中的所有商品，并判断此商品是否具备特殊价格（促销价格）。如果没有，则取正常的商品零售价；如果有，则取当前商品所处促销活动价格。
商品价格计算流程
那么好了，我们便可以把所有涉及更改商品价格的促销活动全部归到此类，例如现价段非常流行的促销活动玩法：
秒杀
秒杀是一种限时类的商品低价促销活动类型。用较低的价格和较短的活动时间，以营造抢购氛围的一种营销玩法。这种活动，在一个用户看来是一个非常新颖好玩的活动，但是对于一个PM来讲，它无非就是一个修改商品价格的促销类型而已，注意我对秒杀活动的定义：限时类的商品低价促销活动类型，核心是商品低价，这直接决定了它是一种修改商品价格的促销活动，也就是第一种类型
其他关于修改价格的营销类型，如：限时折扣，降价拍、团购、拼团等 都可以归类到这一方式
这类型的促销活动，遵循促销核心原则：同类型通过实体进行互斥、不同类型可以相互叠加。此处的实体就是商品。所以这条原则也可以表述为：不同商品可以参与相同的（秒杀、拼团、限时折扣等修改价格）活动；但是相同商品进行互斥，就是说，同一个商品不可以同时参与同一类型的活动，例如：同一个SKU不可以同时参与（秒杀、拼团、限时折扣等修改价格）活动。
第二种类型：修改商品小计
当系统完成了对商品价格的查找之后，就需要将查找出的商品价格分别乘以订单中的每个商品数量，从而计算出每个商品的小计金额。当系统计算出所有商品的小计金额之后，这时候，就可以介入一些营销活动，例如指定商品的：满减、满赠、折扣等。
商品小计金额计算流程
那么好了，我们又可以将指定商品的：满减、满赠、折扣 归类为修改商品小计的营销活动
例如：全场母婴用品，满100减10，满200减30；就是典型的第二种类型营销活动，因为它是针对某种/某类 商品的小计金额来匹配满足那种类型的活动，并在满足活动的商品小计金额基础上进行减、赠、折。
那么我们再次用促销核心规则来捋一捋它的处理逻辑：同类型通过实体进行互斥、不同类型可以相互叠加。此处的实体是商品，所以这对第二种类型的促销活动，我们就可以得出以下结论：
同一个商品，不能同时参与指定商品的（满减、满赠、折扣 等）活动，不同的商品没有限制。
例如：SKUA 不能同时参加满减、满赠、折扣；但是SKUA 参与满减，SKUB参与满赠 这种是被允许的。
我们注意到第二条原则：不同类型可以相互叠加，也就是说，同一个商品虽然不能同时参与同种类型的活动，但是却可以同时参与不同类型的促销活动，例如：SKUA 可以同时参与限时折扣和指定SKUA的满减活动！！！，也就是我们常说的折上折。我们需要做的仅仅是区分促销是属于哪种类型而已
第三种类型：修改订单金额
当系统完成了对商品小计金额的计算之后，就会将所有优惠后的商品小计金额进行叠加，生成一个初步的订单总金额，当系统得到初步的订单总金额之后，又可以介入一些营销活动，例如指定订单的：满减、满赠、折扣和优惠券等。
订单金额计算
那么好了，我们又可以将指定订单类的：满减、满赠、折扣归类为第三种：修改订单金额的营销活动。例如：京东招牌活动全场满88包邮；就是典型的第三种类型营销活动，因为它是针对订单的总金额来匹配满足那种类型的活动，并在满足活动的订单金额基础上进行减、赠、折、优惠券和包邮等。
那么我们再次用促销核心规则来捋一捋它的处理逻辑：同类型通过实体进行互斥、不同类型可以相互叠加，此处的实体就是订单。
所以针对第三种类型的促销活动，我们就可以得出以下结论：
同一笔订单不能同时参与针对订单的：满减、满赠、折扣的活动。
总的来说
之所以会有：同类型通过实体进行互斥、不同类型可以相互叠加，这条原则，是因为它高度遵循了系统计算订单金额的流程---在计算同一类型的促销活动时，如果存在多个相同的活动，除非你人为的告诉系统，优先计算哪条规则，否则，系统就无法进行下去，当你帮助系统排除了这些冲突，问题自然迎刃而解。所以，当你脑洞大开希望实现一个促销功能时，首先应该判断是哪种类型（改商品价格、改商品小计价格还是改订单价格），再根据类型通过实体（商品或者订单）去与其他促销活动区别开，这样就可以玩转各种促销活动了。
说明：这里仅讨论系统层面的电商营销逻辑，保证系统流程上不发生冲突，没有考虑实际的业务场景，但是无论什么业务场景都应该在上述原则范围内行事，不能逾越。比如：针对商品的活动，你可以限制拼团的商品（第一类促销）不能参加指定商品满减（第二类促销），即：在逻辑上允许叠加，但是业务场景上可以限制；但是绝不可能同时使某个商品即参与拼团活动，又参与秒杀活动。这在业务逻辑上就是不被允许的，也就是：可以在上述原则范围内行事，但是不能逾越这个原则。
网友评论
我有几个问题想请教下：
1.优惠条件是满件的促销活动，归到第二类还是第三类促销类型中更合适？我认为是第三类，业务场景有这么几种：N个商品买X件打Y折；N个商品买X件只要Y元
首先，我强烈建议你：同一种促销（优惠券），需要通过商品进行互斥，也就是说，同一个商品只能被一张优惠券选择。这么做并不是说我们不能做，而是即使实现了也会增加用户/运营负担，并且实际场景真的有这种需求吗？能举一个例子吗，什么情况下一定需要这样的使用场景？在用户体验和实际需求上我们需要做出取舍，这也是电商产品价值所在，关于这个你可以看我简书的第二篇关于促销的文章
其次，假如真像你所说，确实有这样的实际需求，需要同一个商品存在两种优惠券内，我的建议是：通过分组的形式来实现，比如商品A 和 B 符合 优惠券1，商品A和商品C 符合优惠券2，那么系统可以给一个默认的选中规则（比如你说的优惠力度大的规则，这个只要定义好规则就行），前台会将优先选择的优惠券2 和购物车所有商品进行匹配，然后将符合条件的商品组合到一起。但是给出切换优惠券的选项，也就是可以把优惠券2切换成1，在切换优惠券的时候，需要同时将商品进行分组，也就是，要把符合优惠券1的所有商品组合到一起。
以上是我的建议，供参考
1. 是不是 同时存在 满减和优惠券 两种形式的促销，而且都是针对部分商品的？还是都是满减优惠？请描述清楚，因为满减 是属于第二种，优惠券是属于第三种
2. 还有这句话 “如果没办法在创建优惠活动时，有办法避免同一个商品A同时在两个活动里面存在，就只能在购物车内进行判断了吧” 我也没有太明白你的意思，最好再组织一下语言