必须在服务端用 request_id + Redis::setex() + 唯一索引三者组合落地，缺一不可：Redis setex仅作快速拦截但会因超时/故障失效，数据库唯一索引须基于业务字段（如request_id）建立并配合ON DUPLICATE KEY UPDATE，request_id必须由客户端首次生成并全程透传，前端还需配合防抖与禁用按钮。
直接说结论：靠前端防抖或按钮禁用拦不住网络重试导致的重复下单，必须在服务端用 request_id + Redis::setex() + 唯一索引三者组合落地，缺一不可。
为什么单靠 Redis setex 会失效
很多人写完 Redis::setex($request_id, 300, 1) 就以为万事大吉，但实际线上出过问题：
- Redis 网络超时或连接池打满时，
setex可能返回 false 或抛异常，后端没做 fallback 就直接放行，重复请求照进不误 - Redis 故障期间所有请求都绕过校验，订单表又没唯一约束，瞬间生成一堆重复订单
-
setex过期时间设成 60 秒，但用户从点击到支付回调耗时 90 秒，第二次重试进来时 key 已过期，被当成新请求处理
所以 setex 只是第一道快速拦截，不是最终防线。
数据库唯一索引怎么建才真正兜底
唯一索引不是随便加个字段就行，关键在选哪个字段、怎么设计表结构：
立即学习“PHP免费学习笔记（深入）”；
- 必须用业务语义明确的字段建唯一键，比如
order_table(request_id)或单独建order_deduction_log(business_key)表 - 不能用
created_at或自增id，它们天然不重复，起不到拦截作用 - 推荐用
INSERT INTO orders (...) VALUES (...) ON DUPLICATE KEY UPDATE status = VALUES(status)，比INSERT IGNORE更可控——万一要补全字段（如支付渠道、回调时间），它能更新；纯拦截则用后者更轻量 - MySQL 8.0+ 可考虑函数索引
UNIQUE KEY uk_req_md5 (MD5(request_id))，但 PHP 端必须同步调用md5($request_id)写入，否则索引失效
request_id 必须由客户端传入，不能服务端每次生成
这是最容易被忽略的实操细节：
- 如果每次请求都用
uniqid('', true)生成新request_id，那重试请求带的是新 ID，Redis 和 DB 都认不出是同一笔操作 - 正确做法是：前端在进入下单页时生成一次 UUID（如 JS 调用
crypto.randomUUID()），存在本地变量或隐藏域，后续所有请求（包括重试）都带上这个值，Header 推荐用X-Request-ID - 后端收到后先校验非空，再传给 Redis 和 SQL，不能容忍空或非法格式的
request_id直接放过 - 如果是内部服务调用（如订单服务调支付服务），
request_id应由上游统一生成并透传，下游只负责使用，不自行覆盖
别跳过前端配合，否则后端压力白扛
后端幂等只是保底，不是替代前端控制：
- 用户狂点提交按钮、F5 刷新、浏览器后退再提交——这些行为产生的重复请求，
request_id是同一个，后端能拦住，但没意义地消耗了资源 - 必须在按钮点击后立即
disabled，同时用fetch或axios的AbortController主动取消未完成请求 - 支付跳转前加 loading 状态，防止用户以为卡住又点一次；回调页面禁止手动刷新（可用
history.replaceState清除历史栈） - PRG 模式（Post-Redirect-Get）对表单类接口依然有效：提交成功后 302 跳转到结果页，避免用户刷新触发重复 POST
真正的幂等性，是前后端在各自边界内各守一关，而不是把所有压力堆给数据库唯一索引去硬扛。
