不靠谱，uniqid()毫秒级精度且无熵，高并发易碰撞；未绑定用户标识会导致跨用户复用。应组合user_id、时间、随机盐与密钥哈希，存Redis并设过期。
用 uniqid() + 用户会话生成幂等令牌靠谱吗
不靠谱，uniqid() 默认不带熵、毫秒级精度，在高并发下极易碰撞；且脱离用户上下文（比如没绑定 session_id 或 user_id）会导致跨用户复用，失去幂等性意义。
真正可用的做法是组合可信因子：
-
hash_hmac('sha256', $user_id . ':' . time() . ':' . random_bytes(16), $_SERVER['HTTP_X_API_SECRET'] ?? 'fallback')—— 依赖密钥防伪造，含用户标识和随机盐 - 把结果截取为 32 位字符串存入 Redis，设置 10 分钟过期：
SET idempotency:abc123 {...} EX 600 NX - 客户端首次请求时提交该令牌，后端用
GET查 Redis，命中则拒绝后续相同令牌的写操作
API 接收幂等令牌后，怎么判断该放行还是拦截
关键不是“有没有令牌”，而是“这个令牌是否已成功处理过”。不能只查存在性，必须区分三种状态：未见过、正在处理中、已成功完成。
推荐用 Redis 的原子操作实现状态机：
立即学习“PHP免费学习笔记（深入）”；
- 收到请求时，先
SET idempotency:abc123 processing EX 60 NX，失败说明已被占用，直接返回409 Conflict - 业务逻辑执行成功后，
SET idempotency:abc123 success EX 86400（长期保留结果供重试查询） - 若业务失败或超时，需主动
DEL idempotency:abc123，否则该令牌会被锁死一小时
注意：NX 是必须的，漏掉就会覆盖状态，导致重复提交被误放行。
前端重复点击提交，后端靠幂等令牌能完全挡住吗
不能。令牌只是服务端防线，它挡不住前端反复发同一请求（比如用户狂点“创建订单”按钮），但能确保即使多个请求抵达，也只创建一个资源。
真实场景要分层防御：
- 前端加按钮禁用 + 防抖：
button.disabled = true，配合setTimeout重置，治标 - 后端校验
Idempotency-Key请求头（不是 query 或 body），避免被日志/代理意外泄露 - 响应必须带明确状态：
201 Created（首次）、200 OK（重试返回缓存结果）、409 Conflict（非法重放） - 不要在
GET上做幂等控制——语义不符，且浏览器/CDN 可能缓存
PHP 里用 file_get_contents() 调用自身 API 做幂等校验会出问题吗
会。本地回环调用（localhost）容易触发连接池耗尽、超时堆积，尤其在 FPM 模式下，还可能绕过 Nginx 的限流或 JWT 校验中间件。
更稳的方式是直连存储层：
- 用
PDO或Redis扩展直接查状态，不走 HTTP 协议栈 - 如果必须走 HTTP（比如微服务拆分），改用
cURL并显式设CURLOPT_TIMEOUT_MS = 300，避免阻塞主请求 - 别把幂等校验逻辑写进 Laravel 的
middleware再调用Http::post()—— 这等于让中间件自己发 HTTP 请求，递归风险高
最常被忽略的一点：幂等键的生命周期必须长于客户端最大重试窗口。比如前端设了 3 次重试、每次间隔 2 秒，那 Redis key 至少得活 10 秒以上，否则第二次重试就查不到记录，变成新请求。
