ThinkPHP 6.x 是当前中小电商类优惠券系统最务实的选择，因其在快速搭建后台、稳定执行定时任务、轻量对接微信卡券三方面高度契合实际需求，而Laravel和Spring Boot则存在场景错配问题。
直接上结论：ThinkPHP 6.x 是当前中小电商类优惠券系统最务实的选择，不是因为它多先进，而是它在「快速出后台 + 稳定跑定时任务 + 轻量对接微信卡券」这三件事上，踩得最准。
为什么不用 Laravel 或 Spring Boot？
不是技术不行，是场景错配。Laravel 的 Eloquent 和包生态确实强，但一个要支持 50+ 商户、每商户独立发券规则、核销需对接 POS 机的系统，光是权限模型和数据隔离就得重写半套中间件；Spring Boot 更不用说，Java 工程师成本高、部署重、改个发券逻辑要编译打包重启。而 ThinkPHP 6 的门面 + 依赖注入 + 多应用结构，配合 FastAdmin 的 CRUD 模板，三天就能跑通「商户入驻 → 创建券 → 后台发放 → 用户领券 → 订单核销」全链路。
优惠券表设计最容易漏掉的三个字段
很多教程只建 coupons 表，字段列一堆 discount、start_time、end_time，上线后立刻翻车。真正跑起来必须加：
-
merchant_id：多商户场景下，不带这个字段，根本没法做数据权限隔离（FastAdmin 的 auth_rule 机制默认不校验数据级权限） -
use_limit_per_user：单用户最多可用次数，不是所有券都“每人限领一张”，比如“老用户月度返券”可能允许每月领 3 张 -
used_count：实时统计已核销张数，别指望靠COUNT(*)查，高并发下单时会锁表；这个字段必须和核销逻辑走同一个事务
微信卡券接口调用失败，90% 是这几个地方写错了
ThinkPHP 里用 Http::post() 调 https://api.weixin.qq.com/card/create，报 {"errcode":40001,"errmsg":"invalid credential"}，别急着查 token，先看这三点：
立即学习“PHP免费学习笔记（深入）”；
-
logo_url必须是公网可访问的 PNG 地址，且尺寸严格为 300×300 像素，大小 ≤200KB —— 本地路径或 base64 字符串直接拒收 -
date_info必须传对象，不能传字符串，例如："date_info": {"type": 1, "begin_timestamp": 1715702400, "end_timestamp": 1718380799}，传成"date_info": "..."就会静默失败 -
location_id_list即使不绑定门店，也必须显式传[]，传null或不传，微信返回errcode:40059
自动发券任务在 CRMEB 里怎么避免“发重”或“漏发”
CRMEB 的定时任务模块确实省事，但它的“秒级调度”和“失败重试”是双刃剑：
- 高频任务（如每分钟扫一次新注册用户）务必加 Redis 锁：
Cache::store('redis')->lock('auto_issue_job', 30)->get()，否则多个 worker 同时执行会重复发券 - 用户筛选条件里别用
last_login_time >= ?这种模糊时间，要用create_time BETWEEN ? AND ?配合任务执行时间戳，否则跨分钟执行时会漏掉刚注册的用户 -
setCouponBatch()返回值不是布尔，而是数组：['success' => 12, 'fail' => 3]，必须检查fail > 0并记录 UID 列表，否则失败用户永远收不到券
真正难的不是写发券逻辑，而是把「商户配置粒度」「用户领取路径」「核销原子性」「微信回调幂等」这四条线拧在一起不打架。大部分项目崩在第 3 步 —— 核销时没锁库存又没回滚订单，导致券用了钱没扣。
