不是有规则引擎么，这么多东西怕是第一个号第一次开所有服务才能享受到，等你以后买就没这么多规则了

包装模式, 每次包装减少对应的金额?

价格打不过 PDD ，售后和物流比不过 JD

第一反应：Naming things is hard, that's one of the hardest parts of programming. -- Linus Torvalds

if () {}if () {}

看着这个求值顺序应该会影响结果?

所以阿里还是很牛逼的，你看 PDD 都搞不出这些直接懒得算，便宜多少就卖多少。

某大厂的处理逻辑：1 、定义好所有的规则配置，形成基本规则项；2 、当用户这个请求进入时，动态构建规则链条，该链条负责规则的过滤、筛选和具体选择；3 、当该请求命中了某些规则之后，会执行对应的逻辑；4 、把执行结果汇总并包装成一个属于该业务的规则数据对象；5 、根据这个规则数据对象，进行预扣减，成功就返回结果；6 、后台发 mq 消息，处理实际的逻辑。

这不是什么好事，对于消费者，压力太大了，得花多少时间去研究，程序猿，测试就更不要说花多少时间在这个上面了。我在瑞典购物这么久，只遇到过两种优惠券（除了 shein 和 temu ），一种就是直接满减，多少，全场通用；第二种，打折商品能不能用。规则相当简单，清晰，只需要过去问问这个能不能叠加用就完了，哪里来这么多弯弯绕绕，相反的，这边的开发，测试，花了太多时间在隐私，权限，合规上。

淘宝京东规则太多了 这个券那个券 这个 VIP 那个立减 有的能叠加有的不能叠加

管他多少个，策略模式封装好，至于用多少个策略，管他尼~

这逻辑多的离谱了 这样都不出 bug 这程序员真的有点东西

哈哈哈，你这逻辑，PDD 便宜是因为 PDD 懒得算，阿里牛逼是因为阿里喜欢算，ahahahahahahhahaha

＃7有没有可能，这是运营策略的原因。以及，有没有可能拼多多在拉新砍价什么的活动上更复杂?

PDD 的规则更简单 if(random() < 0.6)砍单();

我以前就是负责活动、计价的研发。这玩意有什么难的吗？你这里看着一大堆，其实不就“满减”一种类型吗。一般这种优惠本质上就满减，加价购，满赠，代金券，礼品卡这么几种，然后每种优惠可以配使用规则和优先级运营给商品配上不同类型的优惠规则，计算价格的时候按优先级减金额就行了

不是啥难需求吧 每一步实际上输入都是钱输出不一样而已 做几个不同模式的适配本身都是优惠卷 还好没那么夸张

看着很多实际上 本质上都是不同的优惠卷 一样的

有幸做过这类购物车，重构前，chart.js 有 1.5w 行代码，叹为观止，代码屎香四溢，臭不可闻，然后就重构了 2 个月。开发、测试、产品都榨干了。

从结果上来看，没那么难；实际上对大部分公司来说难的一批。一开始需求上只要求立减券，你会上这引擎那模式吗；紧接着叠加折扣券的需求来了，“后天要上线哟”；然后是满减，“上次做折扣券也只用了两天啊，咱先按简单的来”

＃8 大佬，有没有 demo 方案落地代码，挺感兴趣。

liteflow 就是专门处理这种场景的，可以看下 liteflow 的 demo2 liteflow.cc/pages/0a8188/

liteflow.cc/pages/0a8188/＃demo%E6%A1%88%E4%BE%8B2

如果不想用框架，自己写个责任链就行

规则、玩法太多，直接把用户赶去其他平台了

不管是写个界面还是搞个 json 配置, 关键是要把任务甩给运营, 这样就算他配错价格了, 也不是你的锅.

所以我用 pdd ，不用减这减那的说不定还更便宜。。脑子都交给上班了，买东西时根本不想动脑子只想花钱。

跟我们公司的思路一样，我们有 70 多个费用

这个是标准的规则引擎实现的， 然后运营和营销人员只要添加一些规则就能实现这些效果，本身不是开发写死的呦这些规则也往往鼠标在 GUI 界面上点点就能搞定比如 java 的 drools 例子 www.cnblogs.com/binyue/p/17428268.html

开发根据产品梳理出来的价格优惠模型开发就行，比如列举条件和优惠规则（满减，打折等），且这个规则可以随时新增和定义。然后线上运行的时候，各种运营人员（ 88 VIP 会员运营，商家店铺运营，淘金币运营等等）在后台配置对应规则就可以。主要这个规则命中的太多了看起来复杂。

让服务器排列好返给你，我一个 ui 崽给我说这么多

这帖子发的 拿我当 GPT 是吧

简单点，能减钱就直接在优惠里面。搞得消费者有点懵逼，下次不来了。

你在偷窥我？
不同的优惠策略能用的商品不一样，运算过程中是不是得把每个商品在每个策略上优惠的情况都记下来

没啥说的，很简单啊责任链，好像是动态链，我一直在用

能想出这么多名字，产品跟运营也挺厉害的。会不会以后再来个优惠整合战役

这么多东西，数据库压力怎么样？

看到这种需求我心里已经问候产品父母几百遍了

系统底层分工明确、逻辑合理的话，这其实不是什么麻烦事情。每个部分处理自己的职责范围就行。

这肯定得记下来啊，不记下来怎么对账？怎么算收益？怎么算利润？电商会有大订单小订单的概念，大订单会记录总体的优惠使用情况，小订单上面还要做分摊，把每个优惠分摊到单件商品

淘宝感觉还是有点东西，这么复杂的规则在购物车切换商品计算很丝滑，像在客户端计算一样

从技术上说，并不复杂就是运营配的券有点多才显得复杂

卧槽。

还能怎么办？干呗

不干人事，卷用户，券运营，卷开发，卷商家，最后把自己也卷进去了。这一套下来得消耗多少社会隐形成本。

其实非常复杂，涉及到不同的商品优惠池子，池子的优先级，有的池子能继承优惠价，有的是用基准价计算，同时池子有商品交叉。最后要算出各个池子排列的最优解。以上要保证高性能，不能用太暴力的解法。下单时又涉及到各个优惠对应的业务线的一致性。然后是另一个最复杂的部分，优惠券的组合结算及退款处理。

中国人真累，程序员忙着开发折扣券算法，商家忙着计算如何提价叠加折扣券，消费者忙着计算怎么使用折扣券，这难道就是内卷本卷？本来大家可以很简单的

＃9 恕难苟同。这上面除了跨店的基本都是同一个 if 逻辑，设计好对应的接口，就用不到程序员和测试什么功夫了。至于消费者，不想花精力省钱的大可不参加。本就是一种促销手段，你情我愿的，我很懒，也不差这些小钱，所以我每次都不搞这些，我女朋友就乐在其中，并没有什么压力，反而会有额外的情绪价值。

结算的时候做一遍不复杂，难的是搞运营的人要把这些优惠的真正力度搞清楚并估测出一个模型，还有就是现在的电商网站都会帮用户预估到手价，这个也挺麻烦的。

我说的是我自己的想法，你又不苟同的权力呀，又没说你一定要同意我，大佬喜欢，给大佬点赞。千万不要跟我这种小菜鸡计较。

给运营提供个模拟器和配置器随便玩，反正程序上就是减减减

costco 没这么多费劲的规则只有一个：多少钱 off说白了，你别扯那么多，就一条：到底现在多少钱！

优先级这个，运营自己不会头疼么，先打折再减还是先减再打折，要是搞错了，不就亏了

就是查一下数据库，把能用的优惠都查出来。如果没有那种互斥的，就直接用。有的话，就要按顺序遍历，去掉互斥的数据。

这就是我不用淘宝的原因

京东自营都大面积缺货了

作茧自缚

看到这种一层一层的套路 实在是够够的了 不打折不搞活动的时候买 总有种冤大头的感觉

没啥头疼的啊，这得看运营后台做的咋样，交互好就一目了然啊。优先级是必须的，就像楼上说的，有互斥啥的，没优先级有些互斥没法处理

这个肯定是用规则引擎啊，谁闲着没事儿天天给他改这玩意儿，不疯了么。

绷不住了 头一次见到凑齐这么多劵的，不过不得不佩服后面的工程师，但也挺恶心这样的运营的

＃49 你想的太简单了。最终这里的逻辑当然简单。但是整个产品逻辑来看，这里面每一张优惠劵都要有配置平台、封控。并且不同优惠券能否叠加、库存等等。这些需求最终都要堆人的。

😂

不如拼多多

github.com/smogon/pokemon-showdown可以参考宝可梦 随着世代新特性,技能,场地,状态等越来越多 计算也越来越复杂

算盘打的啪啪响，最后发现拼多多每一家都比他便宜
规则复杂,不代表运算量大吧,毕竟现在的 cpu 一秒钟可以运行指令几亿次？.... 纯计算不涉及页面反复渲染一般都不会卡

这个小意思，运营商的计费系统规则比这个复杂太多了

简单问题复杂化，太闲了。

支付和对账部门估计骂娘了

怎么保证复杂规则校验 下 性能在 200ms 以内 目前就碰到这种情况 不知道怎么优化，不敢乱改

求求你别减了，别到时候商家还得给我送东西还倒发钱