Laravel怎么实现队列任务执行失败自动重试上限_LaravelmaxExceptions配置【操作】

maxExceptions 不生效是因为它仅在 Lara vel 8.77+ 中对 redis/database 驱动有效，且必须通过 --max-exceptions 命令行参数启用，不读取配置文件；它限制单次 worker 进程总失败次数，达限即退出，需 Supervisor 自动重启。

### 为什么 `maxExceptions` 不生效？ 说到底，`maxExceptions` 这个配置是 Lara vel 8.77 才开始有的，而且它只认 `redis` 和 `database` 这两种驱动——如果你用的是 `sync`、`sqs` 或者 `beanstalkd`，那就别指望它了。 很多人遇到的坑是：明明在 `app/Console/Kernel.php` 里写了 `$schedule->command(...)->everyMinute()->withoutOverlapping()->onFailure(...)`，可任务失败后依然无限重试。其实那是 Lara vel 的默认行为，跟 `maxExceptions` 压根没关系。 - `maxExceptions` 必须配合 `--max-exceptions=3` 命令行参数使用，不能靠配置文件或模型属性自动加载。 - 它只限制“单次运行中”的失败次数，不是全局累计。比如每天跑一次 `queue:work`，那每天最多失败 3 次，第二天就重置。 - 如果任务抛出的是 `Throwable` 以外的异常（比如 PHP 致命错误、内存溢出），它也捕获不到。 ### `queue:work` 启动时怎么加重试上限？ 直接在启动命令里加 `--max-exceptions` 参数，这是唯一生效的方式。Lara vel 不会从 `config/queue.php` 或环境变量读取这个值。 ```php php artisan queue:work --max-exceptions=2 ``` 需要特别注意的是：`--max-exceptions` 和 `--tries` 是两套机制，千万别搞混： - `--tries=3` 控制“一个任务最多执行几次”（含首次），失败后进 `failed_jobs` 表。 - `--max-exceptions=2` 控制“当前 worker 进程总共允许失败多少次”，达到后进程退出，由 Supervisor 重启。 - 两者同时设置时，`--max-exceptions` 先触发，哪怕单个任务还没到 `--tries` 限制。 ### 数据库驱动下如何让失败任务不进 `failed_jobs`？ 默认情况下，只要任务抛出异常且没被 `try/catch` 捕获，就会进 `failed_jobs` 表——这和 `--max-exceptions` 无关，它是更底层的行为。 如果你只想记录日志、不入库，得手动覆盖失败逻辑： - 在任务类里实现 `failed()` 方法，并在里面跳过 `parent::failed($exception)`。 - 或者在 `App/Providers/AppServiceProvider.php` 的 `boot()` 中监听 `Illuminate\Queue\Events\JobFailed` 事件，然后 `return false` 阻止默认处理。 - 不过要注意：跳过入库后，Lara vel 的 `queue:failed` 和 `queue:retry` 命令就查不到这些任务了。 ### Supervisor 配合 `--max-exceptions` 的关键点 因为 `--max-exceptions` 触发后 worker 进程会退出，所以必须靠 Supervisor 自动拉起新进程，否则队列就停了。 容易踩的坑： - Supervisor 的 `autostart=true` 和 `autorestart=unexpected` 必须启用，否则进程退出后不会重启。 - 别设 `startsecs=0`，否则 Supervisor 可能误判为启动失败而反复重启。 - 日志里看到大量 `Max exceptions exceeded` 提示，说明任务本身不稳定，该修逻辑而不是调高上限。 复杂点在于：你得同时盯住三件事——任务自身的重试逻辑、worker 进程的失败上限、Supervisor 的存活策略。少一个环节，就可能表现为“任务不执行”或“一直卡在失败状态”。