laravel队列重复执行的核心原因是超时机制与去重逻辑不匹配，需双管齐下：用shouldbeunique接口在入队前指纹去重（依赖redis等原子驱动），并调高retry_after值防误重试，同时在handle中加cache::add幂等校验兜底。
Laravel 队列重复执行，核心原因通常不是“代码写错了”，而是超时机制与去重逻辑没对齐。解决方向分两层：一是阻止重复入队（预防），二是确保重复消费不引发副作用（兜底）。两者缺一不可。
用 ShouldBeUnique 做任务级去重
这是 Laravel 8.12+ 原生支持的可靠方案，比手写 Redis 锁更安全、更简洁。
- 在 Job 类中实现 ShouldBeUnique 接口，框架会在调度前自动生成指纹并查 Redis
- 默认指纹 = 类名 + 序列化后的属性值，无需拼接字符串，避免参数顺序/类型错误
- 通过 uniqueId() 定义“哪些算同一个任务”，例如：
return 'update_client_count_' . $this->tenantId; - 通过 uniqueFor() 控制去重窗口，单位秒，建议设为业务合理最大间隔，比如 300（5 分钟）
- 注意：该机制依赖 Redis 或支持原子操作的驱动（如 Database、DynamoDB），不适用于 SQS
调高 retry_after 防止误判超时
重复执行最常见诱因是任务实际耗时 > 队列配置的 retry_after，导致 Laravel 认为失败而重新入队。
- 检查
config/queue.php中对应连接的 retry_after 值（Redis 默认为 60 秒） - 若任务涉及批量 HTTP 请求、大文件处理或数据库聚合，应设为保守上限，例如 300 或 600
- 同时确保 queue:work --timeout 参数比
retry_after至少小 5 秒，防止进程僵死未退出却已释放任务 - 示例命令：
php artisan queue:work redis --timeout=295 --tries=3
在 handle() 中加幂等校验兜底
ShouldBeUnique 解决的是“入队重复”，但网络抖动、手动重试、多实例部署仍可能导致同一任务被多个 worker 拿到并执行。此时需业务层幂等。
- 在 handle() 开头生成唯一业务标识（如
order_id + action_type），存入 Redis 并设 TTL - 使用
Cache::add($key, true, $ttl)原子写入，返回 false 表示已被其他 worker 占用，直接 return - 关键点：TTL 必须覆盖整个 handle 执行时间，建议比预估耗时多留 20% 缓冲
- 避免用
Cache::has() + Cache::put()组合，非原子操作易引发竞态
高优队列额外加固策略
对 high 队列等敏感通道，仅靠去重不够，还需入口防护。
- 分发端加中间件，只允许内网 IP 或带有效服务令牌（
X-Internal-Token）的请求触发 - Nginx 层拦截公开路径，如
location /api/queue/high/ { deny all; }，必要时配合limit_req限速 - 任务类名加入白名单校验，防止攻击者动态构造非法类名投递
- 监听器级熔断：当 high 队列积压超过阈值，自动暂停消费并告警
