thinkphp的retry_after是超时判定阈值而非重试间隔，必须显式配置为大于任务最大耗时（如预估75秒则设90），否则会因误判失败导致无限重试循环。
PHP异步任务执行超时后不会自动重试——这是默认行为，不是bug，也不是配置遗漏。是否重试、何时重试、重试几次，全由队列驱动和任务类共同决定，且不同框架语义差异极大。
ThinkPHP 的 retry_after 不是重试间隔，而是“超时判定阈值”
很多人把 retry_after 误解为“失败后等几秒再试”，其实它只控制一个动作：任务开始执行后，如果超过这个时间还没完成，就强制标记为失败并重新入队（前提是没禁用重试）。它不参与重试策略本身。
-
retry_after = 60表示：任何执行超过 60 秒的任务，不管有没有抛异常，都会被 Redis 驱动主动 kill 并重发 - 这个值必须显式配置在
config/queue.php的connections.redis.retry_after下，ThinkPHP 不会继承全局或默认值 - 若任务真实耗时约 75 秒，
retry_after却设为 60，就会触发无限重试循环——因为每次都被判超时，又立刻重入队 - 建议设为预估最大耗时 × 1.5，并配合日志观察真实执行时间再调整
Laravel 的 $tries 属性控制重试总次数，但需配合 failed() 方法才可靠
Laravel 中 $tries = 3 表示最多尝试 4 次（含首次），和 Hyperf 的 $maxAttempts = 2 语义一致，但关键区别在于失败记录机制。
- 仅靠
$tries不足以定位问题：Redis 驱动默认不写failed_jobs表，失败任务悄无声息消失 - 必须手动实现
failed()方法，或启用--tries参数运行queue:work，否则无法触发失败回调 - 若在
handle()中用sleep(10)模拟长任务，而retry_after（Laravel 叫retry_after或timeout）小于 10，任务会被提前中止，failed()可能不执行 - 真正稳定的重试依赖三要素：显式
$tries、合理timeout、以及failed()中的告警或补偿逻辑
Hyperf 3.1 的 retryAfter() 动态覆盖最灵活，但 sleep() 会阻塞协程
Hyperf 支持在 handle() 中随时调用 $this->retryAfter(30) 覆盖所有上层配置，这是唯一能按错误类型差异化重试的方案。
- 数据库死锁可设
retryAfter(1)立即重试；网络超时则设retryAfter(60)避免雪崩 - 绝对不要用
sleep(5)替代retryAfter()：sleep 会阻塞当前协程，导致整个消费者进程卡住，后续所有任务堆积 - 验证是否生效，最直接方式是在
handle()开头写file_put_contents('/tmp/queue.log', date('H:i:s') . "\n", FILE_APPEND)，再主动抛异常，看日志时间戳间隔是否匹配 - 构造函数传参方式虽灵活，但若 Job 类重写了
__construct()却未调用parent::__construct()，$maxAttempts就完全失效
重试机制最易被忽略的点是：它永远依赖消费者进程持续运行。supervisor 没配、worker 进程意外退出、甚至 php think queue:work 被当成普通命令手工执行——这些都会让重试形同虚设。任务进了队列不等于会被处理，更不等于会被重试。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
