Laravel 11队列不执行主因是QUEUE_CONNECTION仍为sync、配置未清缓存、failed()签名不符Throwable、序列化传递非法对象或autoload未刷新；须改驱动、清缓存、修正接口与方法签名、传ID查库、刷新自动加载并显式指定连接启动worker。
升级 Laravel 11 后队列任务突然不执行、静默失败、failed() 方法不触发或报 Class not found/Serialization of closure 错误，说明新版本对队列生命周期、序列化规则和驱动初始化做了更严格的校验，旧配置和写法已失效。
确认队列驱动是否真正启用
第一步：检查 【.env 中 QUEUE_CONNECTION 必须是 database 或 redis，绝不能是 sync】。Laravel 11 默认仍保留 sync 驱动，但升级后它会彻底绕过所有队列中间件、重试逻辑和 failed_jobs 表，任务一旦抛异常就直接终止，且不记录任何痕迹。
第二步：运行 php artisan queue:work --verbose，观察首行输出——若显示 “Processing jobs from sync…” 则配置未生效；必须看到 “Processing jobs from database…” 或 “redis…” 才算真正进入异步流程。
第三步：执行 php artisan config:clear && php artisan cache:clear。Laravel 11 加强了配置缓存一致性校验，旧缓存可能让 QUEUE_CONNECTION 被强制 fallback 到 sync 而不报错。
修复 failed() 方法不触发问题
方法一：检查 Job 类是否实现 Illuminate\Contracts\Queue\ShouldQueue 接口（Laravel 11 不再兼容仅 use ShouldQueue trait 的写法）。
方法二：确保 failed() 方法签名严格为 public function failed(\Throwable $exception): void。Laravel 11 移除了对 Exception 类型的兼容，传 Exception 会导致方法被跳过。
方法三：验证 failed_jobs 表是否存在且字段完整。Laravel 11 的 queue:failed-table 迁移新增了 uuid 和 connection_name 字段，若沿用旧表结构，failed() 将静默失效。
解决序列化失败与 Class not found
第一步：禁止在 dispatch() 中传递 Request 实例、闭包、控制器对象或未声明 $casts 的模型属性。Laravel 11 默认启用严格序列化校验，这些对象会直接触发 Serialization of closure is not allowed 并进 failed_jobs 表，但 failed() 不执行——因为序列化阶段失败早于 job 实例化。
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
第二步：只传原始类型或可序列化 ID：SendEmailJob::dispatch($user->id, $order->number)，进 handle() 后再查库。
第三步：运行 composer dump-autoload -o。Laravel 11 对自动加载更敏感，类文件移动或命名空间变更后，不刷新 autoload 会导致 Class not found 且无堆栈，任务卡在 pending 状态。
验证队列工作进程是否健康运行
① 在终端中执行 ps aux | grep 'queue:work'，确认进程存在且启动时间合理（非几秒前刚崩溃重启）。
② 检查该进程是否绑定正确连接：php artisan queue:work --connection=database（显式指定比依赖 .env 更可靠）。
③ 添加超时保护：php artisan queue:work --timeout=60 --memory=128。Laravel 11 默认 memory 限制为 128M，超出即杀进程且不写日志，容易误判为“无响应”。
④ 查看 storage/logs/laravel.log 中最近 10 行是否含 Processing 或 Failed 关键字。Laravel 11 默认关闭队列 debug 日志，需手动在 config/queue.php 的对应 connection 下添加 'log' => 'debug'。
