ThinkPHP队列任务失败不重试是因为未正确定义public $maxTries属性、未抛出异常或被--tries参数覆盖；retryAfter控制失败后重试间隔，三者缺一不可。

ThinkPHP 队列任务失败后不重试？检查 maxTries 是否被覆盖

默认情况下，ThinkPHP 的队列任务不会自动重试——哪怕你写了 handle 方法也一样。关键在任务类是否显式声明了 maxTries 属性，且未被配置或命令行参数覆盖。

常见错误现象：php think queue:listen 执行失败后直接丢弃任务，日志里只有一次执行记录，没看到重试日志；或者明明设了 maxTries = 3，但只试了 1 次就进 failed_jobs 表。

• maxTries 必须定义为 public 属性，不能是 private/protected
• 如果在命令行启动时加了 --tries=1，它会强制覆盖类里的 maxTries（哪怕你写的是 5）
• Laravel 风格的 tries() 方法（如 return $this->tries(3);）在 ThinkPHP 中无效，纯属混淆
• 使用 php think queue:work --once 时，即使 maxTries > 1，也不会触发重试逻辑——它只跑一次就停

queue.php 配置文件里没有 maxTries 这个选项

ThinkPHP 的队列核心配置（config/queue.php）不提供全局 maxTries 设置项。它只管连接方式、驱动、表名这些基础信息，任务级别的重试策略必须下沉到每个任务类里控制。

容易踩的坑：queue.php 里塞 'maxTries' => 3 是无效的，框架压根不读这个键；有人误以为改了 default 或 connections.database 下的某项就能影响重试，其实完全无关。

• 真正起作用的只有任务类中的 public $maxTries = 3;
• 若用 Redis 驱动，重试依赖 attempts 字段计数，该字段由框架自动维护，无需手动操作
• 数据库驱动下，failed_jobs 表的 attempts 列值，和任务实际执行次数一致，可用于排查是否真的重试了

重试间隔靠 retryAfter 控制，不是延迟队列

retryAfter 决定的是“失败后隔多久再入队”，不是“首次执行前延迟多久”。它和 delay 语义不同，也不能混用。

典型误用场景：想让失败任务 5 秒后再试，却在构造函数里写 $this->delay(5)，结果发现第一次都延迟了 5 秒，失败后立刻重试（甚至重复入队）。

• public $retryAfter = 5; 表示每次失败后，等 5 秒再把任务重新推回队列
• 该值单位是秒，且仅对支持重试的驱动生效（database / redis），sync 驱动无视它
• 如果 $retryAfter 设得太小（比如 0.1），高并发下可能造成任务密集重入，拖垮数据库
• 注意和 timeout 区分：timeout 是单次执行超时时间，超时也会触发重试，但不算作“异常抛出”

任务抛出异常才触发重试，返回 false 不行

ThinkPHP 判定任务失败的唯一依据是：执行过程中是否抛出未被捕获的异常。返回 false、null 或静默退出，都会被当作“成功完成”，不会重试。

这和有些框架的“返回布尔值决定成败”逻辑完全不同，也是最容易忽略的一点。

• 必须用 throw new Exception('xxx'); 或继承自 Exception 的自定义异常
• 在 handle 方法里 try-catch 住所有异常但没 re-throw，等于主动屏蔽重试机制
• 日志中看到 App\Job\SendEmail::handle() executed successfully，基本说明没抛异常
• 第三方 SDK 调用失败时，要检查它是否只返回错误码而非抛异常，必要时需手动包装

重试逻辑看似简单，但 maxTries、retryAfter、异常抛出三者必须同时到位，缺一不可；任何一处写错，任务就变成“最多执行一次”的状态，而错误日志往往不报错，只安静消失。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！