1、优惠券shux
优惠券种类
- 满额减
- 无门槛立减
- 折扣券 >>（需要的话也可拆分 满额折扣、无门槛折扣券）
使用规则
- 限量发行/不限量
- 限量领取/不限量 >> 限量领取常用于一些优惠力度很大的优惠券，如推广期用于拉新的优惠券。这种优惠券只希望每个用户能获取一次，以后不可在获得。
- 是否可叠加使用 >> 同一种优惠券是否可以领取多张且同时对一个订单使用(这是设计初期考虑的一个规则，但是反复考虑还是摒弃了，无论对于 优惠券创建者或者 使用者，这都是一个会让人产生疑惑的规则，越简单的方法往往越有效)
- 是否可共同使用 >> 针对一笔订单，如果希望有多个优惠券可以同时使用，那就需要用到这个规则了，如果希望还是简单点就好了，那这也是一个可以摒弃的
有效期
- 永久有效
- 固定有效期 >>（2019-1-2 -- 2019-1-31 这种，通常作为特定活动的优惠券如 双十一优惠券）
- 领取后固定天数有效 >>（领取后30天生效。这种的话，是可以作为长期使用的优惠券，但又希望客户领取后尽快使用）
关联产品/分类
- 全场通用
- 关联分类/属性 >> 海鲜券（关联海鲜分类）、夏季产品打折券
- 关联产品 >> 最常见的一种方式，绑定 不固定的多个产品，可点击优惠券进入相应 产品列表页。
到这里，优惠券coupons 表基本就出来了；
关联产品/分类 是不是需要做成多对多（many to many）关系,这个看情况而定，个人觉得如果你需要在产品页面展示 相关优惠券信息，那就用 多对多来做，如果不需要，直接 用 array（text）存储关联产品/分类的ID即可
2、优惠券的领取/分发
自动领取
自动领取其实就是在用户下单的时候，自动判断 有没有可用优惠券，有的话自动领取/使用
优点：可以让用户更简单的使用优惠券，
缺点：用户没用去主动领取优惠券，而且下单的时候有可能都没有发现使用了优惠券，这时候优惠券的意义就失去了（让用户觉得捡了便宜）
手动领取
最常见的优惠券使用方式，进入商城通过 banner广告（手机app可以尝试首页弹窗领取优惠券）等引导用户领取优惠券同时刺激用户消费
可以通过配合 下单页面的 优惠券快捷领取来使用，类似淘宝，防止用户漏领券而懊恼
后台分发
- 自动分发 >> 系统自动给过生日的用户分发优惠券、推荐好友注册后自动获得优惠券 等。
- 手动分发 >>给一些需要补偿的客户手动分发优惠券
后台分发模式 可以和 前两种中的一种用于公共构成优惠券的领取方式
用户优惠券表 customer_coupons 用于存储 用户获取的优惠券信息，关联 coupons（多对一）、customers（多对一），用户优惠券的有效期，如果没有设置，自动继承 关联coupon有效期，可以通过 模型监控者（customerCouponObserver）来完成。
3、优惠券的使用和退回
- 用户选择可用优惠券 ——》
- 用户下单 ——》
- 系统创建订单（——相关优惠券状态设为已使用——） ——》
- 用户支付 ——》
- 支付成功 ——》
- 订单状态改为已支付--END
上面是一个正常的使用优惠券购物逻辑。
优惠券会在 系统订单创建的时候变为 已使用，但其实这时候用户还没有支付，如果当前用户停止支付步骤，订单就会成为未支付订单。（未支付订单可继续支付，保持优惠券已使用状态）
这时候用户去下其他订单，这张优惠券 是不可在使用的（已使用状态）。
当用户 取消未支付订单（或系统自动删除未支付订单）时，我们需要将 优惠券状态重置为 未使用（可通过监控者 orderObserver 监控订单删除事件来完成）。
（还有一个需要考虑的就是退款的状况，退款以后是不是需要退回相关优惠券；如果需要退款也退还优惠券的话，可能需要判断 当前订单的退款总额 是否达到订单支付金额来进行退还前提判断）
用户优惠券表 （customer_coupons ）与 订单表 （orders）之间的关系，看具体设计而定（一对一/多对一 ）
4、优惠券何时进行验证
- 创建订单 >> 创建订单时主动验证 优惠券有效性（是否当前用户优惠券、时效性、满额、关联产品等）
- 未支付订单 继续支付 >> 因为优惠券的时效性原因，可能存在 未支付订单重新支付时候，优惠券已经过期，但是不建议这时候继续验证。（因为别人刚下单的时候 还能用，现在突然不能用了，会让人很蛋疼。）