maxexceptions 不生效是因为它仅在 laravel 8.77+ 中对 redis/database 驱动有效，且必须通过 --max-exceptions 命令行参数启用，不读取配置文件；它限制单次 worker 进程总失败次数，达限即退出，需 supervisor 自动重启。
为什么 maxExceptions 不生效？
因为这个配置只在 Laravel 8.77+ 版本中存在，且仅对使用 redis 或 database 驱动的队列任务有效；如果你用的是 sync、sqs 或 beanstalkd，它完全不会起作用。
常见错误现象是：明明在 app/Console/Kernel.php 里写了 $schedule->command(...)->everyMinute()->withoutOverlapping()->onFailure(...)，但失败后还是无限重试——其实那是 Laravel 默认行为，跟 maxExceptions 没关系。
-
maxExceptions必须配合--max-exceptions=3命令行参数使用，不能靠配置文件或模型属性自动加载 - 它只限制「单次运行中」的失败次数，不是全局累计；比如你每天跑一次
queue:work，那每天最多失败 3 次，第二天又重置 - 如果任务抛出的是
Throwable以外的异常（比如 PHP 致命错误、内存溢出），它也捕获不到
queue:work 启动时怎么加重试上限？
直接在启动命令里加 --max-exceptions 参数，这是唯一生效方式。Laravel 不会从 config/queue.php 或环境变量读取这个值。
示例：
php artisan queue:work --max-exceptions=2
注意：--max-exceptions 和 --tries 是两套机制，别混用：
PHP中文网提供Laravel 13.2.0版本下载，Laravel框架 是基于 PHP 8.3+ 的高性能框架，官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索，支持属性驱动开发与队列路由，大幅提升开发效率。相比旧版，13.2.0 优化了缓存 TTL 管理与实时通信，无需 Redis 即可横向扩展。作为现代 Web 开发首选，它兼顾安全与极速体验，助您快速构建企业级应用。
-
--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阻止默认处理 - 注意：跳过入库后，Laravel 的
queue:failed和queue:retry命令就查不到这些任务了
Supervisor 配合 --max-exceptions 的关键点
因为 --max-exceptions 触发后 worker 进程会退出，所以必须靠 Supervisor 自动拉起新进程，否则队列就停了。
容易踩的坑：
- Supervisor 的
autostart=true和autorestart=unexpected必须启用，否则进程退出后不会重启 - 别设
startsecs=0，否则 Supervisor 可能误判为启动失败而反复重启 - 日志里看到大量
Max exceptions exceeded提示，说明任务本身不稳定，该修逻辑而不是调高上限
复杂点在于：你得同时盯住三件事——任务自身的重试逻辑、worker 进程的失败上限、Supervisor 的存活策略。少一个环节，就可能表现为“任务不执行”或“一直卡在失败状态”。
