ThinkPHP队列重试失败需检查五点：一、任务类必须声明public $maxTries；二、命令行--tries参数需与预期一致；三、config/queue.php中删除无效tries配置；四、启用failed日志驱动并仅在handle()中调用attempts()；五、database驱动不支持$maxTries，应改用Redis等原子驱动。
如果您在ThinkPHP中发现队列任务失败后未按预期重试，或重试次数与配置不符，则可能是由于重试策略在多个层级存在冲突或配置缺失。以下是解决此问题的步骤：
一、在任务类中显式声明 public $maxTries 属性
ThinkPHP 的队列重试上限由任务类自身的 public $maxTries 属性决定，该属性具有最高优先级，且必须为 public 访问权限。若未定义，框架将采用默认值 0（即无限重试），而非常见误认为的 1 或 3。
1、打开目标任务类文件，例如 app/job/SendNotificationJob.php。
2、在类体顶部添加属性声明：public $maxTries = 3;。
立即学习“PHP免费学习笔记（深入）”；
3、确保该属性未被 private 或 protected 修饰，否则框架无法读取。
二、校准队列处理器命令行参数 --tries
通过 php think queue:work 启动时传入的 --tries 参数会覆盖任务类中的 $maxTries 设置（除非任务类使用更高优先级的动态方式），因此需确保其值与业务预期一致且未被 Supervisor 等进程管理工具意外覆盖。
1、停止当前运行的队列监听进程。
2、使用明确重试次数启动：php think queue:work redis --tries=3 --timeout=120。
3、若使用 Supervisor，检查其配置中 command 字段是否包含 --tries=3，避免因遗漏导致回退至默认值。
三、确认未在 config/queue.php 中错误添加 tries 配置项
ThinkPHP 的队列核心配置文件 config/queue.php 不识别 tries 键，任何在此处添加的 'tries' => N 均无效，且可能造成维护误解。该文件仅控制驱动连接、表名、retry_after 等基础参数。
1、打开 config/queue.php 文件。
2、搜索并删除所有形如 'tries' => \d+ 的键值对。
3、验证 retry_after 值是否合理（例如 90），确保其大于任务预期执行时间，防止任务被提前释放而重复消费。
四、启用失败任务记录并验证 attempts 行为
当使用 Redis 驱动时，failed_jobs 表不会自动写入失败记录，除非显式启用失败日志驱动；同时，$this->attempts() 方法仅在 handle() 方法内可用，用于获取当前执行轮次（从 1 开始计数）。
1、在 config/queue.php 中确认 failed 配置已启用：'driver' => 'database' 且表名指向有效数据表。
2、在任务类的 handle() 方法中调用 $this->attempts() 判断重试阶段，例如：if ($this->attempts() >= 3) { /* 触发降级逻辑 */ }。
3、切勿在构造函数中调用 $this->attempts()，此时重试上下文尚未注入，将返回 0 或抛出异常。
五、检查数据库驱动对重试的支持限制
若使用 database 驱动，$maxTries 属性完全无效，因其缺乏原子计数能力；重试行为必须依赖手动调用 release() 并自行维护重试次数字段，且高并发下易引发重复执行。
1、确认当前队列连接类型：config('queue.default') 是否为 database。
2、如确需 database 驱动，请改用 Redis 或 Beanstalkd 等支持原子操作的驱动以启用原生 $maxTries 支持。
3、若必须使用 database 驱动，则需在任务逻辑中自行实现重试计数：读取数据库 jobs 表的 attempts 字段，判断是否小于阈值，再决定是否调用 $this->release(60) 延迟重入。
