laravel调度器本身不支持失败重试，重试逻辑需由被调度的队列任务或artisan命令内部实现；推荐封装为队列任务并配置$tries和retryuntil，或在命令中手动捕获异常重试。
Laravel 任务调度（Scheduler）本身不直接支持失败重试，它只负责按时触发命令；真正的重试逻辑必须落在被调度的 队列任务 或 Artisan 命令 内部。也就是说，调度器是“发令员”，而重试能力得由执行单元自己承担。
让被调度的任务具备重试能力
如果你用 $schedule->command('report:generate')->daily(); 这类方式调度一个 Artisan 命令，该命令默认是同步执行、无重试机制的。要实现失败重试，推荐两种可靠路径：
-
把耗时/易失败逻辑封装成队列任务：在命令的
handle()方法里，不直接执行业务，而是分发一个可重试的队列任务，例如：SendNotification::dispatch($user)->onQueue('high');
然后在SendNotification类中设置public $tries = 3;和$this->retryUntil(now()->addSeconds(10)); -
在命令内部手动捕获异常并重试：适用于简单场景，比如调用外部 API 失败时最多再试 2 次：
for ($i = 0; $i callExternalApi(); break; } catch (RequestException $e) { if ($i === 2) throw $e; sleep(1); } }
利用队列驱动天然支持重试
这是最主流、最健壮的做法。只要你的调度命令最终触发的是一个实现了 ShouldQueue 接口的任务，Laravel 队列系统就会自动接管重试流程：
- 确保
.env中设为QUEUE_CONNECTION=redis（生产环境首选） - 在任务类顶部声明重试策略：
public $tries = 3;<br>public function handle() { $this->retryUntil(now()->addSeconds(12)); } - 配置
config/queue.php中 redis 的'retry_after' => 90，保证大于retryUntil设置值
失败后主动告警与人工干预
即使有自动重试，关键任务失败仍需及时感知：
- 在任务的
failed()方法中发送邮件或钉钉通知：Notification::route('database', 1)->notify(new JobFailedAlert($exception)); - 启用失败任务记录：
php artisan queue:failed-table && php artisan migrate
之后可用php artisan queue:failed查看，php artisan queue:retry 123手动重试 - 监听全局
JobFailed事件，在EventServiceProvider中统一处理日志和监控上报
避免调度器自身失败导致任务漏跑
调度器本身虽不重试，但要防止它“失灵”：
- 服务器 Cron 必须稳定运行每分钟一次：
* * * * * cd /var/www && php artisan schedule:run >> /dev/null 2>&1 - 给调度命令加超时保护和错误回调：
$schedule->command('backup:run')<br> ->daily()<br> ->onFailure(function () { \Log::error('Backup command failed'); }); - 定期检查
storage/logs/schedule-*.log确认调度是否正常触发
