刚刚国内过完双十一不久，美国过完黑五，很多人可能都借机会通过打折、优惠券等手段买了很多有用没用的东西。

因为我是做支付的，所以有很多的机会接触优惠券相关的开发和维护，一路走来，踩进去的，看着别人踩进去的，以及听说的各种坑真的不算少了。本来还以为仅仅是我们自己会遇到。昨晚和大学时候的同学吃饭，遇到有朋友也是做过 Coupon 的，谈论起来，也是坑友。看样子 Coupon 确实是令很多公司工程师头大的东西。

如果你不能理解为什么这个东西可以这么复杂，那么我们就来看一些场景：

首先你有固定价值的优惠券，还有按百分比的优惠券。

然后这个优惠券可能有个有效期。

接着还有个可以使用的付款总额的最低限额。

是不是可以组合使用多张 Coupon，使用的顺序如何？

不能使用多张，但是用户有多张，使用的顺序如何？

这些都很容易理解，也都不算困难，咱们再看看一些升级版的：

购物车里商品加加减减，什么时候需要触发哪些规则的重新叠加？

特殊商品或者特殊商品的组合才能使用优惠券，以及改单的处理，要如何完善？

用户买了单，突然又改单，减掉一些商品，或是加上一些商品，但是 Coupon 的有效期可能在订单之后，改单之前，又怎么处理？

用户取消订单的一部分，优惠券不能满足使用的最低限额，结果导致账单需要额外付款，规则又该如何？

一些 优惠券 有使用次数限制，比如一次使用，无限次使用，或者 100 次使用。应该在系统中怎么实现？有人取消订单，是不是可以重新激活 优惠券？

如果这些还不够复杂，想想这些情况：

一个开发团队按照严谨而完美的产品设计实现了所有的优惠卷相关的需求。发布一两个月后，非常稳定，所以开发人员都转去做别的了。

一个新的项目或者产品开始了，需要加一些 优惠券上的新需求。一些新的开发人员很快改完了。

又一个新的项目或者产品开始了，需要加一些 优惠券上的新需求。一些新的开发人员很快改完了。

又一个新的项目或者产品开始了，需要加一些 优惠券上的新需求。一些新的开发人员很快改完了。

然后，大家做的一些设定被彼此打破，一些开始的设计里绝对没有问题的地方开始出现逻辑漏洞。于是另一个工程师开始来修这个漏洞。不小心牵扯了取消订单或者该订单时候的一些设定，于是又出现另一个漏洞，和另一个漏洞……

最要命的，是这个时候已经没有人有整个设计、所有产品、写下来的、没有写下来的背景知识。于是，不同的人都来改一刀。整个 优惠券 的实现就好像每次你挖了个地雷，却又埋了个定时炸弹……

所以这个问题有没有解呢？有，而且说起来其实没有那么复杂。

第一，就是不管最开始设计优惠券系统的人，还是后来在上面加新需求的人。不论这个人是产品经理，还是技术领导。得真的知道或者了解所有优惠券可能出问题的地方，应该怎么统一设计。千万不要过于轻视这个问题，认为是一个工程师改几行代码就完的事。其实设计对了，大部分的问题是可以避免的。

第二，一定要有统一的文档，保持更新。这样所有的人都知道有哪些设定，有哪些是必须考虑的，有哪些改动可能会影响之前的设计的。

第三，所有奇葩用法的测试例。包括上面所有场景的各种组合。这样，如果后面人有改动改变了一些假设，就很有可能让之前的测试例过不了。

技术上来说，差不多就是这样。但其实更多现实中的问题，是优惠券开发的问题被认为很简单，因此没有非常清晰哪个组或人对其负责，或者没有预留充分的时间和资源去严密地设计和实现。最后可能导致的结果，就是各种 bug，用户投诉， 以及由漏洞而引起的不必要的损失。