Token安全核心在于生命周期管理而非生成：必须绑定用户会话与操作上下文，严格在业务事务提交后删除，高并发下用Redis DEL保证原子性，并统一返回409状态码明确提示重复请求。
直接用 session 或 redis 存一次性的 token，配合表单隐藏字段和接口校验，就能拦住大部分重复提交。关键不在“怎么生成 token”，而在“什么时候删、删不掉怎么办、并发时怎么防穿透”。
生成 Token 必须绑定用户会话和操作上下文
只调用 bin2hex(random_bytes(16)) 生成随机串是不够的。Token 要能区分用户、动作类型、甚至目标资源 ID，否则 A 用户的提交可能被 B 用户的重复请求绕过。
- 推荐拼接方式：
sha256($_SESSION['user_id'] . $action_type . $resource_id . time())，再截取前 32 位作 token -
$action_type比如'order_create'或'withdraw_submit'，避免所有接口共用一套 token 池 - 不要把 token 直接塞进 URL 查询参数——容易被日志/代理缓存；用 POST body 或 header 传
校验失败时必须明确返回状态码和错误原因
很多实现只返回 400 或空响应，前端无法区分是网络重试、还是真被拦截。后端要主动告诉客户端“这个 token 已用过”或“已过期”。
- 建议统一返回 JSON：
{"code": 409, "message": "duplicate request", "token_status": "used"} - HTTP 状态码优先用
409 Conflict（语义最贴切），次选422 Unprocessable Entity - 别在
try/catch里吞掉RedisException或PDOException：连接失败时应降级为宽松校验（比如只校验时间戳），而不是直接放行
删除 Token 的时机必须严格落在业务成功之后
不是收到请求就删，也不是校验通过就删——得等数据库写入完成、事务 commit 成功后才删。否则会出现“校验通过 → 写库失败 → token 已删 → 用户重试失败”的雪球问题。
立即学习“PHP免费学习笔记（深入）”；
- 典型错误写法：
if (checkToken($token)) { delToken($token); doBusiness(); } - 正确顺序：
if (checkToken($token)) { doBusiness(); if ($success) { delToken($token); } } - 如果用 Redis，建议用
DEL命令而非EXPIRE配合 TTL：前者原子性更强，后者在高并发下可能因时钟漂移导致误删或漏删
真正难的不是生成和比对 token，而是当用户疯狂点击提交按钮、网络超时自动重发、或者用 Postman 手动重放请求时，你的 delToken() 是否还在事务里稳住，以及 Redis 连接断了会不会让整个幂等逻辑静默失效。
