优惠券系统核心是状态驱动、规则引擎与并发安全设计：拆分为CouponTemplate（模板规则）和UserCoupon（用户凭证）；核销需幂等、分布式锁与库存校验；发放分预生成与按需生成；规则通过CouponCalculator接口扩展。
Java中实现营销优惠券系统，核心在于券的生命周期管理（发放、领取、使用、核销、过期）和业务规则的灵活控制（门槛、限用范围、叠加策略、库存扣减）。不是简单存个“折扣金额”，而是围绕“状态驱动 + 规则引擎 + 并发安全”来设计。
优惠券模型设计：状态与规则解耦
一张优惠券本质是“可执行的营销策略实例”。建议拆分为两个主实体：
- CouponTemplate：模板层，定义通用规则——面值、类型（满减/折扣/立减）、使用门槛（满100减20）、适用商品/品类/店铺、有效期（固定周期或领取后N天）、每人限领张数、是否可叠加等。用枚举+JSON字段（如rule_config）存储动态规则，避免频繁改表结构。
- UserCoupon：用户凭证层，记录具体发放结果——用户ID、模板ID、券码（可选）、状态（未使用/已核销/已过期/已作废）、领取时间、过期时间、核销时间、核销订单号。状态变更必须通过状态机（如用StateMachine库或简单switch）驱动，禁止直接update status。
核销流程：幂等 + 分布式锁 + 库存校验
核销不是“查+改”两步，而是原子性闭环操作：
- 前置校验：检查UserCoupon状态是否为“未使用”、是否在有效期内、订单金额是否满足门槛、商品是否在适用范围内（查CouponTemplate关联规则表）、是否超出每人限用次数（需查该用户历史核销记录）。
- 并发控制：同一张券被多次请求核销时，用Redis分布式锁（key为user_coupon:{id}）或数据库乐观锁（version字段）保证仅一次成功。
- 原子更新：在事务内完成三件事——更新UserCoupon状态为“已核销”、记录核销订单号和时间、扣减CouponTemplate的已用库存（if exists）。推荐用MyBatis的@SelectKey或自增version保障一致性。
- 幂等设计：核销接口必须接受外部传入的唯一业务ID（如order_no），先查该订单是否已核销过此券，避免重复扣减。
发放与库存：预生成 vs 按需生成
根据场景选择策略，直接影响性能与灵活性：
立即学习“Java免费学习笔记（深入）”；
- 预生成券码：适用于限量大额券（如双11神券）。提前批量生成UserCoupon记录（status=“未领取”），发券即update status=“已领取”。优点是核销快；缺点是占用数据库空间，且未领取券长期占库存。
- 按需生成：适用于通用满减券。用户点击“领取”时才插入UserCoupon记录，并校验模板剩余总库存（total_count - used_count ≥ 1）。需用数据库行锁（SELECT ... FOR UPDATE）防止超领。
- 库存统一维护：CouponTemplate表中total_count（总发放量）、used_count（已核销数）必须由核销成功事件异步更新（或事务内同步更新），不可靠前端或缓存计数。
规则扩展：轻量级规则引擎思路
避免硬编码if-else判断满减、折扣逻辑：
- 将计算逻辑抽象为接口CouponCalculator，不同券类型实现不同策略（如FullReductionCalculator、PercentDiscountCalculator）。
- 规则参数外置：在CouponTemplate.rule_config中存JSON，如{"threshold":100,"discount":20}，运行时解析后传入计算器。
- 叠加控制：在核销前调用CouponCombinationValidator，根据模板配置的can_combine字段和当前订单已选其他券类型，决定是否允许共用。
基本上就这些。优惠券系统不复杂但容易忽略状态一致性与高并发下的数据安全，把模板、凭证、规则、核销四层边界划清，再补上锁和幂等，就能支撑日均百万级核销了。
