应统一配置队列最大尝试次数：一、检查config/queue.php中勿误加tries键；二、校准queue:work命令的--tries参数；三、在Job类设$tries属性；四、可排队通知类需单独设$tries；五、排查Horizon配置覆盖。
如果您在 Laravel 应用中发现队列任务因临时异常反复重试，或因配置不一致导致部分任务无限重试、部分任务立即失败，则可能是由于最大尝试次数在多个层级存在差异性配置。以下是解决此问题的步骤：
一、检查并统一 config/queue.php 全局配置
该配置文件定义了所有队列连接的默认行为，其中 retry_after 控制任务被标记为“已释放”前的等待秒数，而 tries 选项（若存在）影响基于数据库或 Redis 的失败任务表处理逻辑；但需注意：Laravel 原生队列驱动（如 database、redis、sync）并不直接通过此文件设置单任务最大重试次数，真正生效的是命令行参数或任务类属性。
1、打开 config/queue.php 文件，定位到对应连接配置块（如 'redis' 或 'database'）。
2、确认未误加 'tries' => N 键值对——该键在标准配置中并不存在，添加后不会被 Laravel 队列系统识别。
3、检查 retry_after 值是否合理（例如 90），确保其大于任务预期执行时间，避免任务被提前释放并重复消费。
二、校准队列监听命令中的 --tries 参数
当使用 php artisan queue:work 或 php artisan queue:listen 启动处理器时，--tries 参数会为本次运行的所有任务设定统一的最大尝试次数，该值优先级高于全局配置但低于任务类内声明。
1、停止当前运行的队列进程。
2、使用明确参数启动监听器：例如 php artisan queue:work redis --tries=3 --timeout=120。
3、若使用 Supervisor 管理进程，检查其配置文件中 command 字段是否遗漏 --tries，避免因配置缺失导致实际采用默认值 3 而与预期不符。
三、覆盖任务类内部 $tries 属性
在具体 Job 类中直接定义 $tries 属性可实现任务粒度的精确控制，该设置具有最高优先级，会完全忽略命令行参数和配置文件中的相关设定。
1、打开目标任务类，例如 app/Jobs/SendEmailCode.php。
2、在类体中添加公共属性：public $tries = 5;。
3、若需动态控制，可在 dispatch 时链式调用：dispatch(new SendEmailCode)->tries(2);（仅 Laravel 9+ 支持）。
四、验证可排队通知的 $tries 设置
Laravel 5.7+ 开始支持为继承 Illuminate\Notifications\Notification 并实现 ShouldQueue 的通知类单独配置重试次数，该配置独立于普通 Job 类，且必须显式声明才生效。
1、确认通知类已实现 ShouldQueue 接口。
2、在类中添加属性：public $tries = 1;。
3、移除任何试图通过 via() 或通道配置间接控制重试的行为，此类方式无效。
五、排查 Horizon 配置覆盖行为
若项目启用 Laravel Horizon，其配置文件 config/horizon.php 中的 'defaults' 或 'environments' 区块可能通过 'tries' 键强制指定任务重试次数，该配置会覆盖命令行及任务类设置。
1、打开 config/horizon.php，搜索 'tries' 关键字。
2、检查 'supervisor-default' 或当前环境对应的 supervisor 配置块中是否存在 'tries' => N。
3、若存在且值与业务需求冲突，修改为所需数值或删除该行以退回到任务类控制逻辑。
