TP6队列任务执行失败需排查入队、消费及闭环处理，核心是配置、进程、驱动对齐；必须禁用sync驱动，改用redis/database并正确配置host/port/database、retry_after；消费者须用Supervisor常驻管理；Job类需设tries、记录日志、处理失败；生产环境应切failed存储至Redis、清理失败任务、关键任务改用RabbitMQ。

TP6队列任务执行失败，不能只看“报错不报错”，重点要排查任务是否真正入队、是否被消费、失败后有没有闭环处理。常见问题不是代码写错了，而是配置、进程、驱动三者没对齐。

确认队列驱动已切换为异步模式

默认的 sync 驱动会让任务同步执行（无日志、无延迟、无法重试），表面成功实则没走队列流程：

• 检查 config/queue.php 中 'default' => 'redis'（或 'database'），不能是 'sync'
• Redis 驱动必须显式配置三项：'host'、'port'、'database'（注意：旧版 'select' 已废弃）
• 'retry_after' 值需大于任务最长执行时间（如发短信耗时 8 秒，此处至少设为 10）

确保消费者进程已启动且持续运行

调用 Queue::push() 只是把任务写入 Redis 或数据库，不会自动触发执行：

• 手动运行监听命令：php think queue:work --queue=default --daemon（加 --daemon 才是常驻模式）
• 生产环境务必用 Supervisor 管理，配置中 autostart=true 和 autorestart=true 缺一不可
• Supervisor 的 command 必须用绝对路径，例如：/usr/bin/php /var/www/tp6/think queue:work --daemon

在 Job 类中规范处理失败逻辑

任务执行出错时，不捕获异常会导致任务直接丢弃；不控制重试次数会引发雪崩：

• 每个 Job 类定义 public $tries = 3;，框架会自动限制最大重试次数
• 在 fire() 方法内主动判断：if ($job->attempts() >= 3) { // 记录告警或推送到死信队列 }
• 消费失败必须记录日志：Log::error('OrderJob failed', ['id' => $data['id'], 'attempts' => $job->attempts()]);
• Redis 延迟队列场景下，push 失败要重试（如网络抖动），可用 while 循环 + 指数退避

生产环境必备的容错补丁

万级并发下，光靠默认配置扛不住，需主动加固：

• 将失败任务存储从数据库切到 Redis：'failed' => ['type' => 'redis']，避免 failed_jobs 表锁表
• 设置 retry_after ≥ stopwaitsecs（Supervisor 配置项），防止平滑重启时任务被重复消费
• 每日定时清理：php think queue:flush 清空已确认失败的任务，防止堆积
• 关键任务（如支付回调）改用 RabbitMQ 驱动，开启消息持久化与 ACK 确认机制