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 下的某项就能影响重试，其实完全无关。
立即学习“PHP免费学习笔记（深入）”；
- 真正起作用的只有任务类中的
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、异常抛出三者必须同时到位，缺一不可；任何一处写错，任务就变成“最多执行一次”的状态，而错误日志往往不报错，只安静消失。
