优惠券核销并发出错主因是check-and-update拆分为两步，导致超发；需依赖数据库原子操作（如SELECT FOR UPDATE或Redis Lua脚本）或分布式锁兜底，避免仅靠缓存校验。
优惠券核销为什么总在并发下出错？
因为多数实现把 check-and-update 拆成两步：先查库存，再扣减。中间一旦有并发请求进来，就可能超发。Gin 本身不解决这个问题，得靠数据库层或应用层加锁来兜底。
实际场景里，最稳妥的是用数据库的原子操作——比如 PostgreSQL 的 UPDATE ... WHERE stock > 0 RETURNING id，或者 MySQL 的 SELECT ... FOR UPDATE（需事务 + InnoDB 行锁）。别依赖内存缓存做最终校验，缓存没事务语义，容易漏。
- Redis 实现核销必须配合 Lua 脚本保证原子性，单条
DECR不够，得同时判断剩余量、更新状态、写核销记录 - 如果用了分库分表，
coupon_id必须作为分片键，否则跨库SELECT FOR UPDATE会失效或锁表 - Gin 中间件里别直接调 DB 查询，应统一走 service 层，方便后续替换为乐观锁或分布式锁
如何让同一张优惠券支持多种核销方式？
硬编码 if-else 判断核销类型（如「扫码核销」「订单自动核销」「后台强制核销」）会导致逻辑散落、难以测试。应该把核销行为抽象成接口，每种方式实现自己的 Verify() 和 Apply() 方法。
例如定义 type Redemption interface { Verify(ctx *gin.Context, coupon *Coupon) error; Apply(ctx context.Context, coupon *Coupon, extra map[string]interface{}) error }，然后用 map 注册：redemptionMap["scan"] = &ScanRedeemer{}。路由里通过 c.Param("type") 动态获取实例。
立即学习“go语言免费学习笔记（深入）”；
- 不同核销方式对幂等性要求不同：扫码需防重复提交，订单核销依赖订单状态机，后台核销要记录操作人
- 别在
Verify里修改 DB 状态，只做校验；真正扣减放Apply，且必须包含重试补偿逻辑 - 额外参数（如核销码、订单号）统一走
extramap，避免接口频繁变更
Gin 中怎么透传核销上下文又不污染 handler？
核销过程涉及用户身份、设备指纹、渠道来源、风控结果等多个上下文字段，全塞进 c.Request.URL.Query() 或 header 容易混乱，也难做统一校验。
推荐用 Gin 的 c.Set() + 自定义中间件预处理：写一个 ParseRedeemContext() 中间件，从 header（如 X-Channel）、query（trace_id）、token claims 里提取关键字段，组装成结构体塞进 context，后续 handler 直接 c.MustGet("redeem_ctx").(*RedeemContext) 取用。
- 结构体字段要导出，但别暴露 DB 字段名，比如用
ChannelCode而非channel - 中间件里做基础校验（如
ChannelCode是否在白名单），失败直接c.AbortWithStatusJSON(400, ...) - 别把敏感字段（如用户手机号）写进日志，
RedeemContext的String()方法要屏蔽它们
为什么核销成功后还要异步发消息？
同步调用风控、营销、积分服务会拖慢响应，且任一环节失败导致核销回滚复杂。更合理的是核销 DB 成功后，立刻投递一条 MQ 消息（如 coupon.redeemed），由下游消费者各自处理后续动作。
注意：MQ 发送必须和 DB 更新在同一事务里，否则会出现「DB 更新成功但消息丢失」。PostgreSQL 可用 LISTEN/NOTIFY，MySQL 推荐用 binlog + canal 或事务内发消息（如使用 github.com/go-gorm/gorm 的 AfterCommit 钩子）。
- 消息体别包含完整 coupon 对象，只传
coupon_id和redeem_id，下游按需查 - 消费者要做幂等：用
redeem_id做唯一索引，插入失败即跳过 - 别在 Gin handler 里起 goroutine 发消息，事务未提交时 goroutine 可能读到旧数据
真正麻烦的不是写代码，是核销状态在多个系统间的一致性——DB、缓存、MQ、下游服务，任何一个环节掉队，用户就会看到「已核销但没生效」。盯住那几个关键 ID 的生命周期，比堆功能重要得多。
