直接查看 failed_jobs 表的 exception 字段可定位90%失败原因；需手动建表、修复 failed() 方法签名、确认 QUEUE_CONNECTION 配置、避免 payload 截断，并依赖数据库直查排查。
直接看 failed_jobs 表里的 exception 字段，90% 的失败原因就藏在里面——不是猜配置、不是重启服务，先读错是什么。
查 failed_jobs 表前必须确保表已存在
5.5 版本不自动建 failed_jobs 表，得手动补：
- 运行
php artisan queue:failed-table生成迁移文件 - 再执行
php artisan migrate，否则所有失败任务都丢进黑洞，连日志都没地方存 - 如果迁移报错“Base table or view not found”，说明
jobs表也没建，得先跑php artisan queue:table再 migrate
failed() 方法里别写 strict 类型提示
Laravel 5.5 的 failed() 方法参数可能为 null（比如超时或手动 $this->fail()），但很多人写成 Exception $e，PHP 就直接 fatal error：
- 错的写法：
public function failed(Exception $e)→ 报错Argument 1 ... must be an instance of Exception, null given - 对的写法：
public function failed(\Exception $e = null)→ 带反斜杠 + 默认值 - 别省略
\，否则 PHP 在App\Jobs命名空间下找Exception类，根本不存在
queue:work 启动就退出？先看驱动初始化是否失败
5.5 对配置敏感，queue:work 静默退出大概率是驱动没起来：
- 检查
.env：确认QUEUE_CONNECTION=database或redis，**绝不能是sync**（sync 模式下queue:work无意义） - 删掉旧键名
QUEUE_DRIVER，5.5 只认QUEUE_CONNECTION - 进
php artisan tinker执行resolve('Illuminate\Queue\QueueManager')->connection()，抛异常就说明 config/queue.php 里对应连接配置缺字段（比如 database 驱动漏了'table' => 'jobs'） - Redis 用户特别注意：
REDIS_HOST别写localhost，Docker 或 Homestead 环境得用redis或宿主 IP
重试时 payload 截断是 MySQL TEXT 的锅
5.5 默认用 TEXT 存 failed_jobs.payload，但某些任务序列化后超长，MySQL 会静默截断，重试时 unserialize() 直接崩溃：
- 现象：
php artisan queue:retry 123报错ErrorException: unserialize(): Error at offset - 验证方法：查
failed_jobs表，看payload字段长度是否接近 65535（TEXT 最大） - 临时解法：把字段改成
MEDIUMTEXT（ALTER TABLE failed_jobs MODIFY payload MEDIUMTEXT） - 长期建议：避免在任务里传大数组、资源句柄或闭包——5.5 不支持序列化闭包，一传就炸
5.5 的队列没有 Horizon 这类可视化工具，所有排查都得靠命令和数据库直查；exception 字段里那几行堆栈，比任何文档都准——别跳过它。
