cache::remember结合请求指纹可实现安全幂等控制，需排除动态参数、设60～300秒窗口期、用redis存储，并在中间件中统一校验x-idempotency-key头。
用 Cache::remember + 请求指纹做幂等控制
ThinkPHP 本身不提供开箱即用的接口幂等性中间件，得自己搭一层“请求锁”。最稳妥的做法是：对每个请求生成唯一指纹（比如 md5($user_id . $uri . $params_json)），再用缓存标记它是否已执行过。
关键不是存什么，而是存多久——幂等窗口期一般设为 60～300 秒足够，太短拦不住重试，太长占缓存还可能误伤正常请求。
-
Cache::remember()比直接Cache::has() + Cache::set()更安全，避免竞态：先查缓存，命中就跳过；未命中则写入并执行业务逻辑 - 指纹必须排除动态参数，比如时间戳、随机数字段，否则同一逻辑请求每次指纹都不同
- 不要用
session或数据库做幂等锁，高并发下容易成为瓶颈；redis是首选驱动
拦截重复提交时，Token 验证要和表单生命周期对齐
前端带 _token 的 POST 请求，后端用 Token::check() 验证，这本身不是幂等控制，但常被误当替代方案。问题在于：这个 token 一次有效、验证即销毁，而幂等要求的是“相同请求多次进来只执行一次”，两者语义不同。
如果你在接口里混用 Token::check()，会导致前端重试失败（第二次没 token），但用户感知是“提交失败”，而非“已成功”。这不是幂等，是防抖。
- 表单类接口可用
Token::check()+ 前端禁用提交按钮，适合低频、人工触发场景 - API 接口别依赖它做幂等，尤其移动端或支付回调这类自动重试场景，token 过期或丢失会直接中断流程
- 如果非要结合使用，记得在
Token::check()通过后立刻用Cache::remember补一层幂等锁，覆盖 token 生命周期外的重试窗口
middleware 里怎么安全加幂等头校验
很多团队想靠请求头如 X-Request-ID 或 X-Idempotency-Key 实现幂等，这思路没问题，但 ThinkPHP 默认不解析这些头，得手动取、手动校验。
注意：request()->header('X-Idempotency-Key') 返回的是字符串，空值或空白要提前过滤，否则缓存键变成 md5(' ')，所有无头请求都撞进同一个桶。
- 建议统一规定 header 名为
X-Idempotency-Key，长度限制 32～64 字符，服务端截断或拒绝超长值 - 校验逻辑必须放在全局中间件（如
app/middleware/Idempotent.php），且位置要比路由调度早，否则控制器里再处理就晚了 - 命中幂等缓存时，返回 HTTP 200 + 原始响应体（不是简单 return ['code'=>0]），否则前端无法区分“真成功”和“幂等返回”
Redis 缓存失效策略影响幂等可靠性
用 Cache::remember('idempotent_'.$key, 120, function(){...}) 看似简单，但实际运行中常因 Redis 驱动配置出问题导致失效不及时。比如：cache.redis.handler 配成 Predis 却没装扩展，降级到 file 缓存，根本扛不住并发。
更隐蔽的问题是：ThinkPHP 默认缓存前缀是 think:，而你用 Cache::get('idempotent_abc') 查的时候，实际 key 是 think:idempotent_abc，但如果其他模块改过前缀，就对不上。
- 务必检查
config/cache.php中default驱动是否为redis，且stores.redis.handler能正常实例化 - 幂等 key 建议显式拼接前缀，比如
'idempotent_' . $key，避免依赖全局配置变动 - 线上遇到“偶尔重复执行”，第一反应不是逻辑错，先查 Redis 是否满、是否主从同步延迟、缓存是否被外部脚本清空
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
