laravel防重复提交有五种方法：一、唯一请求令牌；二、数据库唯一索引约束；三、redis分布式锁+事务标记；四、eloquent模型事件拦截；五、http idempotency-key头验证。
如果您在 Laravel 应用中处理表单提交时遇到重复提交导致数据库重复插入、余额被多次扣减或订单重复创建等问题，则可能是由于缺乏幂等性控制机制。以下是实现事务内防重复提交的多种方法：
一、使用唯一请求令牌（Token-Based Idempotency）
该方法通过为每次表单请求生成唯一且一次性的 token，并在服务端绑定该 token 与事务状态，确保同一 token 只能成功执行一次事务。
1、在表单页面渲染时，调用 csrf_token() 并额外生成一个基于时间戳和随机数的 idempotency token，存入 session 或 Redis，设置 10 分钟过期。
2、将该 token 作为隐藏字段嵌入表单，例如：。
3、在控制器中，先校验该 token 是否存在且未被标记为已处理；若已存在，直接返回 409 Conflict 响应并终止后续逻辑。
4、若 token 有效，在 DB 事务开始前立即将其状态置为 processing，事务成功后更新为 completed；若事务失败则置为 failed 并保留 token 供重试判断。
二、数据库层面幂等键约束（Idempotent Key Enforcement）
该方法利用数据库唯一索引强制拦截重复数据写入，将幂等性保障下沉至存储层，不依赖应用状态管理。
1、为业务关键表添加复合唯一索引，例如在 orders 表中添加 (user_id, idempotency_key) 的唯一约束。
2、前端在发起请求前生成稳定且可复现的 idempotency_key，如对用户 ID、时间戳、订单摘要内容进行 SHA-256 哈希并截取前 16 字符。
3、控制器中在事务内执行插入操作时捕获 Illuminate\Database\QueryException，检查错误码是否为 MySQL 的 1062 或 PostgreSQL 的 23505。
4、若捕获到唯一键冲突异常，查询数据库确认该 idempotency_key 对应记录是否已存在且状态合法；若存在则直接返回原记录，不新建事务分支。
三、Redis 分布式锁 + 事务标记（Distributed Lock with Atomic Flag）
该方法适用于多节点部署场景，通过 Redis 原子操作保证同一请求在集群中仅有一个实例进入事务流程。
1、在表单提交接口入口，使用 Redis::set($key, $value, 'EX', 300, 'NX') 尝试设置以 idempotency_token 为 key 的锁，超时设为 5 分钟。
2、若返回 false，说明该 token 已被其他请求占用，立即返回 HTTP 状态码 425 Too Early 或自定义错误提示。
3、若获取锁成功，在事务开启前，向 Redis 写入标记 idempotency:status:{token} = pending，并设置相同过期时间。
4、事务提交成功后，更新 Redis 标记为 completed；若事务回滚，则更新为 failed，允许客户端根据状态决定是否重试。
四、Laravel Eloquent 模型事件钩子拦截（Model Event Hook Guard）
该方法在模型持久化生命周期中注入幂等性检查逻辑，适用于已有模型结构且不希望修改控制器主流程的场景。
1、在对应模型中注册 creating 和 updating 事件监听器，通过 static::$unguarded = true 临时解除批量赋值保护以便读取原始输入。
2、从 request() 中提取 idempotency_token 或业务唯一标识字段，在监听器中调用 self::where('idempotency_key', $token)->exists() 查询是否已存在同 key 记录。
3、若存在且状态非草稿或已生效，则抛出 Illuminate\Validation\ValidationException 并附带错误消息“该操作已被执行，请勿重复提交”。
4、若不存在，继续执行默认保存逻辑；同时在 created 事件中触发异步任务，将该 token 同步写入 Redis 作二次校验缓存。
五、HTTP 请求头级幂等请求标识（Idempotency-Key Header Validation）
该方法遵循 RFC-9110 中关于 Idempotency-Key 的语义规范，将幂等性识别完全交由 HTTP 层处理，解耦业务逻辑。
1、要求前端在 POST/PUT 请求头中携带 Idempotency-Key:
2、在中间件中解析该 header，检查其长度是否符合 UUID v4 格式，不符合则返回 400 Bad Request。
3、使用该 key 查询 idempotency_logs 表，查找 status 字段为 completed 的记录；若存在，直接返回原响应体及 200 状态码。
4、若未命中，启动数据库事务并在事务末尾插入一条 idempotency_logs 记录，包含 key、response_hash、status、created_at 字段，确保幂等日志与业务数据原子一致。
