高并发支付接口必须同时满足幂等、防重放、原子扣款、异步解耦四条件；回调需Redis指纹+DB状态双重校验；前端幂等key推荐md5(userId_productId_分钟级时间戳)；扣款与状态变更须拆分事务，外部调用一律移出事务；Redis故障时降级为文件缓存或单次无指纹提交并告警。
支付接口在高并发下必须同时满足幂等、防重放、原子扣款、异步解耦四个硬性条件，缺一不可。只做签名或只加锁，都挡不住真实流量冲击。
支付回调必须用 Redis 指纹 + 数据库状态双重校验
第三方支付平台（微信/支付宝）的异步通知可能重复推送多次，仅靠 sign 验证和数据库 WHERE status = 'pending' 更新，无法防止网络重传导致的状态覆盖。
- 先查订单：用
DB::table('orders')->where('order_no', $orderNo)->lockForUpdate()->first()获取行锁，避免并发更新冲突 - 再判状态：若
$order->status !== 'pending'，直接返回 success，不进后续逻辑 - 最后写指纹：用
Redis::setex('pay_callback_fingerprint:' . $orderNo, 3600, $notifyId)记录本次通知 ID，下次同 ID 到达时直接跳过 - 注意：
lockForUpdate()必须在事务内执行，且不能放在if ($order->status === 'pending')之后——否则锁没起作用就放行了
前端提交订单时的幂等 key 不能只拼用户 ID 和商品 ID
单纯用 user_id . '_' . product_id 作 Redis key，会被恶意构造绕过；加时间戳到秒级又容易因网络延迟导致同一操作被判定为两次。
- 推荐组合：
md5($userId . '_' . $productId . '_' . floor(time() / 60))，按分钟切片，兼顾重试容忍与防爆破 - key 过期时间设为
EX 120（2 分钟），比业务超时略长，但不过度占用内存 - 校验失败时返回 HTTP 429 + JSON
{"message": "请勿重复提交"}，前端据此禁用按钮，而非弹窗提示后继续发请求 - 别在指纹校验前做库存查询或权限检查——这些操作失败后指纹还占着，用户反而卡死无法重试
扣款与状态变更必须拆到不同事务，且禁止在事务里调外部 API
把「更新订单状态 → 调用微信统一下单 → 写支付流水 → 发 MQ 消息」全塞在一个 DB 事务里，只要微信接口抖动，整个事务就卡住，连接池迅速耗尽。
- Web 层只做两件事：生成订单（
Order::create()）、入队（PayOrderJob::dispatch($order)） - 队列任务中再执行微信下单，成功后用原子 SQL 更新：
DB::update('UPDATE orders SET status = ?, pay_no = ? WHERE id = ? AND status = ?', ['paid', $payNo, $orderId, 'unpaid']) - 影响行数为 0？说明已被其他队列进程抢先更新，直接退出，不抛异常、不重试
- 所有外部调用（微信、短信、MQ）必须放在事务外，失败走独立补偿机制，不能拖垮主流程
Redis 故障时的降级策略不是“关开关”，而是有损保命
当 Redis 宕机，SETNX 全部失败，如果直接返回错误或放行，要么用户反复点击生成多单，要么整个下单链路瘫痪。
- 降级逻辑要写在中间件里，检测
Redis::ping()失败后，改用cache()->store('file')->put(...)（仅限单机部署环境） - 若连 file cache 都不可用，则允许一次无指纹提交，但强制记录告警日志：
Log::warning('Redis down, allow one-time order submit for user ' . $userId) - 同时触发钉钉/企业微信告警，要求 5 分钟内人工介入，而不是等监控系统轮询发现
- 最危险的是把降级逻辑写成“try/catch 后走 DB 查询去重”——这等于把 Redis 压力转嫁给 MySQL，高并发下更早崩
真正难的不是写对某一行代码，而是所有环节都默认自己会失败：Redis 可能挂、MySQL 可能锁表、微信可能超时、队列可能堆积。每个组件都要有明确的 fallback 路径，且 fallback 本身不能成为新瓶颈。
