ThinkPHP 不内置优惠券系统，需开发者自主设计；coupon 表必须包含 type、condition_amount、use_range、used_count/total_count 四字段，以支持灵活营销规则与并发安全。
ThinkPHP 本身不提供现成的优惠券系统，所谓“营销工具逻辑汇总”其实是开发者基于框架能力自行组装的一套业务规则。能不能跑通，关键不在 ThinkPHP 版本，而在你如何设计 coupon 表结构、控制发放节奏、校验使用条件、防止并发超领——这些地方一出错，发出去的券就可能作废或被刷光。
优惠券表设计必须包含这 4 个字段
很多项目一开始只建了 id、name、discount，结果后面加满减、限品类、限时段时全得加字段、改逻辑、补数据迁移。实际要从第一版就预留：
-
type：整数类型，区分1（满减）、2（折扣）、3（立减）、4（包邮），别用字符串存 -
condition_amount：满多少可用，允许为0（即无门槛） -
use_range：枚举值，如0（全站）、1（指定商品 ID 列表，存 JSON 字符串）、2（指定分类 ID） -
used_count和total_count：用于限制每人限领 X 张、全场共 X 张，别靠应用层计数，必须数据库WHERE used_count + <code>UPDATE ... SET used_count = used_count + 1
领取接口必须做幂等 + 并发防护
用户狂点“立即领取”，或用脚本批量请求，会导致同一张券被重复生成多条记录。ThinkPHP 的 Db::transaction() 不足以解决，因为事务只锁行，不锁“用户+券ID”这个业务维度：
- 在领取前先查
CouponUser表是否存在user_id和coupon_id组合，有则直接返回已领取 - 插入前加唯一索引：
ALTER TABLE coupon_user ADD UNIQUE INDEX uk_user_coupon (user_id, coupon_id); - 用
INSERT IGNORE或ON DUPLICATE KEY UPDATE替代普通insert()，避免抛出异常中断流程 - Redis 可做辅助限频，但不能替代数据库唯一约束——缓存可能丢失，数据库才是最终防线
核销时的金额计算别硬编码写死
常见错误是写一个 calculateDiscount() 函数，把满减、折扣、立减逻辑全塞进去，后续加“阶梯满减”或“叠加券”就崩。正确做法是把计算逻辑下沉到优惠券模型里：
立即学习“PHP免费学习笔记（深入）”；
- 每个
Coupon实例实现apply($orderAmount, $items)方法，返回实际抵扣金额 - 满减券：先过滤可参与商品（按
use_range匹配），再取这些商品总价，满足condition_amount才生效 - 折扣券：注意是“订单总金额打几折”还是“仅对某类商品打折”，后者需传入
$items数组并逐个判断 - 务必在核销前重新查一遍券状态：
status = 1（启用）、start_time <= NOW()、end_time >= NOW()、used_times < max_use_times
最易被忽略的是“已领取未使用券”的过期清理。别指望用户主动放弃，得用定时任务每天扫 coupon_user 表中 status = 0 AND end_time < NOW() 的记录并更新为失效——否则数据库里堆几千条僵尸数据，连带影响用户端“我的优惠券”列表性能。
