Laravel默认不重试失败任务，必须在任务类中明确定义public $tries = 3;等整数值才会触发重试流程，否则直接写入failed_jobs表；$backoff数组需匹配$tries长度，retryUntil()优先级高于$backoff，混用将导致后者失效。
失败任务不会自动重试，必须显式配置 $tries 才会进入重试流程——没设这个属性，哪怕写了 $backoff 也完全无效。
为什么任务失败后直接进 failed_jobs 表，根本不重试？
这是最常被忽略的配置前提。Laravel 默认行为是：任务抛异常 → 标记失败 → 写入 failed_jobs → 结束，**不重试**。
-
$tries必须在任务类中明确定义为整数（如public $tries = 3;），不能只靠config/queue.php全局设置 -
sync驱动下重试逻辑被完全绕过，它根本不算“队列”，只是同步执行 + 抛异常 - 使用
php artisan make:job JobName --tries=0生成的任务，$tries被显式设为 0，等同于禁用重试 - 若任务里写了
retryUntil()，但同时又定义了$tries，后者会覆盖前者，导致截止时间失效
$backoff 和 retryAfter() 到底该用哪个？
二者功能重叠但优先级不同，混用容易踩坑。
-
$backoff是数组形式，比如[1, 5, 60]，表示第 1/2/3 次失败后分别等待 1 秒、5 秒、60 秒再重试；数组长度必须 ≥$tries - 1，否则后续重试全部 fallback 到最后一个值 -
retryAfter()是方法，返回一个\DateTimeInterface，比如return now()->addSeconds(10);，它在单次任务实例中生效，优先级高于$backoff - 不要在一个任务里既写
$backoff又写retryAfter()—— 后者会静默胜出，前者形同虚设 - 高优任务想秒级重试，别依赖
$backoff的最小单位（秒），改用dispatch($job)->delay(now()->addMilliseconds(100))更精准
重试命令 php artisan queue:retry 有哪些硬限制？
这个命令是人工干预唯一可靠的入口，但它不是万能的。
- 重试单个任务：
php artisan queue:retry 123，ID 来自failed_jobs.id，不是任务 UUID 或原始 job ID -
php artisan queue:retry all会遍历全表重试，但不会跳过已成功重试过的记录 —— 若任务有副作用（如发短信、扣款），可能重复触发 - Horizon 和 Telescope 只能查、不能重试；Web 界面重试需自行实现接口，且必须防范反序列化失败（比如闭包、
Request对象无法还原） - 如果任务失败时数据库写
failed_jobs失败（连接中断、磁盘满、表结构异常），这条记录就彻底丢失，queue:retry无从谈起
任务里写 dd() 或 exit 会发生什么？
这不是调试问题，是队列进程稳定性问题。
-
dd()和exit会让当前 worker 进程直接终止，后续所有排队中的任务都会卡住，直到 supervisor 重启它 - 超时杀进程（
--timeout=60）和你手动exit效果一样：任务中断、不重试、不进failed_jobs（因为还没走到写库那步） - 真正安全的调试方式是打日志：
\Log::info('debug', ['data' => $this->payload]);，或用 Telescope 查看上下文 - 任何阻塞操作（
sleep()、无 timeout 的 HTTP 请求、file_get_contents()大文件）都可能让任务在超时前就卡死，worker 进程僵住，比失败更难排查
