laravel不支持按异常类名自动匹配重试延迟，需在handle()中try/catch判断异常类型后手动dispatch()->delay()重发，$tries建议设为1，避免框架默认重试干扰分类逻辑。
队列任务失败后怎么按错误类型决定重试间隔
直接看结论：Laravel 本身不支持「按异常类名自动匹配不同重试延迟」，必须手动在 failed() 或 __construct() 中控制 $tries 和 $backoff，且 $backoff 数组只对当前任务实例生效，不能动态响应异常类型。
常见错误现象是：把 $backoff = [1, 5, 60] 写死在任务类里，结果所有错误（比如网络超时、数据库唯一冲突、第三方 API 返回 401）都走同一套退避策略，既浪费资源又掩盖问题。
- 真正需要的是：捕获异常后，判断
get_class($exception)，再调用dispatch()->delay()手动重发，而不是依赖框架默认重试 -
$tries建议设为1，避免框架自动重试干扰你的分类逻辑 - 若用 Redis 队列，注意
delay()时间精度是秒级，毫秒级控制需改用later()+ 自定义时间戳
Laravel 任务中如何区分「可重试错误」和「该进 failed_jobs 表的错误」
关键不在重试逻辑，而在「什么时候不该重试」。Laravel 的 failed() 方法只在所有重试耗尽后触发，但很多错误根本不该重试——比如 Illuminate\Database\QueryException 中的唯一索引冲突，重试 10 次还是失败；而 GuzzleHttp\Exception\ConnectException 就值得等几秒再试。
- 在
handle()里用try/catch包住核心逻辑，对明确不可重试的异常直接 throw，不 catch；对可重试的异常 catch 后调用self::dispatch($this->data)->delay(now()->addSeconds($delay)) - 不要在
failed()里再 dispatch 新任务，否则会绕过队列中间件、丢失原始 job ID，也难追踪链路 - 检查
failed_jobs表里的exception字段，如果高频出现Illuminate\Queue\MaxAttemptsExceededException，说明你没管好重试入口，被框架兜底了
使用 retryUntil() 和 withBackoff() 的实际效果差异
retryUntil() 是 Laravel 9.2+ 加的特性，它让任务最多运行到某个时间点为止，不是固定次数；withBackoff() 则是给单个 dispatch 调用设置退避数组，优先级高于类属性 $backoff。两者不互斥，但容易误用。
-
retryUntil()对「临时性依赖服务恢复时间不确定」的场景更实用，比如等待外部系统维护结束，写成retryUntil(now()->addMinutes(30)) -
withBackoff([5, 30, 120])只影响这次 dispatch，适合根据上游响应动态调整，比如 API 返回Retry-After: 60头时，就用withBackoff([60]) - 注意：如果任务类定义了
$tries = 3，又调用了withBackoff([5])，实际只会重试 1 次（取 min），不是叠加
Redis 驱动下 delay() 和数据库驱动下重试行为不一致的原因
根本区别在于：Redis 队列靠 ZSET 排序实现延迟，精度高、无轮询开销；数据库队列靠 available_at 字段 + 定时扫描，受 queue:work --sleep 和 --max-jobs 影响大，延迟可能漂移几十秒。
- 线上环境别用 database 驱动做精确退避，尤其当
sleep=3且任务量小时，delay(1)可能变成等 3 秒才执行 - Redis 下
delay(now()->addSeconds(0.5))会被截断为 0，实际立刻执行；想控制亚秒级，得用later()+ Lua 脚本微调，但没必要 - 如果你的任务必须兼容两种驱动，统一用
delay(now()->addSeconds(1))起步，别低于 1 秒
catch + dispatch()->delay()，Laravel 队列层根本不认识你的业务异常。
