优惠券过期判断必须用数据库时间，即expire_at > now()；状态字段应语义化存储如enum；并发领券需select ... for update加行锁；expire_at作为固有属性不可修改。
优惠券过期判断必须用数据库时间，别信应用服务器时钟
MySQL 里 CURDATE() 和 NOW() 是唯一可信的过期依据。应用层用 PHP/Java 获取的当前时间可能和数据库有几秒甚至几分钟偏差，尤其跨机房部署时，WHERE expire_at > '2024-05-20 10:00:00' 这种写死时间字符串或传入客户端时间，会导致已过期券被误判为有效。
实操建议：
- 所有过期校验统一走
expire_at > NOW()，别用DATE(NOW())截断，否则忽略时分秒精度 - 建表时
expire_at必须是DATETIME或TIMESTAMP，别用DATE类型——优惠券常需精确到秒级发放与核销 - 如果业务要求“当日零点失效”，字段存的是
2024-05-20 00:00:00，查询时仍用expire_at > NOW()，别手动生成当天零点时间再比较
状态字段不能只靠 status INT(1) 枚举硬编码
优惠券状态流转比想象中复杂：未发放、已发放、已使用、已过期、已作废、退款中……光靠 status TINYINT 存数字，查 bug 时根本不知道 status = 4 到底代表什么，协作和后期维护全靠猜。
实操建议：
- 用
ENUM('pending', 'issued', 'used', 'expired', 'revoked')或VARCHAR(20)存语义化值，配合注释说明每个值含义 - 状态变更必须走事务 + 明确条件检查，例如核销前要同时满足：
status = 'issued'且expire_at > NOW()且used_at IS NULL - 避免在应用层拼接 SQL 判断状态，比如
"WHERE status IN (1,2,3)"—— 改个状态码就漏逻辑，直接查WHERE status IN ('issued', 'used')更安全
并发领券必须加行锁，别只靠唯一索引兜底
用户高并发抢限量优惠券时，仅靠 UNIQUE KEY (user_id, coupon_template_id) 防重复领取，会漏掉超发：两个事务几乎同时查到库存 > 0，都通过校验，然后都 insert 成功。
实操建议：
- 领券前先
SELECT stock FROM coupon_template WHERE id = ? FOR UPDATE，锁住模板行，再判断并更新stock = stock - 1 - 把「扣减库存」和「生成用户券记录」放在同一事务里，中间别做 HTTP 调用或 sleep
- 注意
FOR UPDATE在可重复读（RR）隔离级别下才锁间隙，避免幻读；读已提交（RC）下需配合SELECT ... LOCK IN SHARE MODE或改用乐观锁（version 字段 + CAS 更新）
已核销券的 expire_at 仍要参与查询，别删或清空
有些同学觉得“已用掉的券过期时间没用了”，就把 used_at 非空的记录里 expire_at 设为 NULL 或 '1970-01-01'。结果运营要查“过去三个月内核销但原本有效期大于7天的券”，SQL 直接失效。
实操建议：
-
expire_at是券的固有属性，一旦生成就不该修改，哪怕已核销 - 查询历史数据时，状态和有效期要分开过滤：
WHERE status = 'used' AND expire_at > '2024-02-01'，而不是依赖字段是否为空 - 如果担心
expire_at索引太宽影响性能，可加复合索引(status, expire_at)加速常用组合查询
真正麻烦的是状态和时间耦合的边界场景：比如券在 10:00:00 过期，用户 09:59:59 提交核销请求，但数据库事务到 10:00:05 才提交成功。这时候 expire_at > NOW() 在事务开始时为 true，但提交时已 false —— 这类问题得靠应用层幂等 + 数据库约束双重卡住，不是单改字段能解决的。
