failed_jobs 表在 RabbitMQ 场景下通常为空，因为 RabbitMQ 驱动默认通过 AMQP 协议层处理失败（如未 ack、DLX 路由），不经过 Laravel database 驱动的失败写入路径；只有显式启用 fallback 或自定义逻辑才会写入该表。
failed_jobs 表和 RabbitMQ 没有直接关联，它只由 Laravel 的 database 驱动写入；用 RabbitMQ 时，这个表默认不被使用，除非你手动启用 fallback 或自定义失败处理逻辑。
为什么 failed_jobs 表在 RabbitMQ 场景下通常为空？
RabbitMQ 驱动（如 laravel-queue-rabbitmq）默认不依赖 failed_jobs 表存储失败任务。它的失败流转走的是 AMQP 协议层机制：消息未 ack → 重回队列或发往死信交换机（DLX）。Laravel 的 queue:failed 命令查不到记录，是因为任务根本没进过数据库驱动的失败写入路径。
- 只有当队列连接配置为
database驱动时，failed_jobs表才会被自动写入 - RabbitMQ 驱动的失败消息默认不落库，而是通过
reroute_failed => true发往指定 exchange - 若你看到
failed_jobs里有数据，大概率是混用了 driver（比如QUEUE_CONNECTION=database但实际发到了 RabbitMQ），或手动调用了fail()方法触发了数据库写入
想让 failed_jobs 表在 RabbitMQ 中生效，必须显式干预
这不是开箱即用的功能，需要你主动桥接两层失败机制：
- 在任务类中定义
public $tries = 3，并确保retry_after（config/queue.php 中 RabbitMQ 连接项）设得足够长，否则消息可能在 Laravel 重试前就被 RabbitMQ 丢弃 - 在
failed()方法里手动写入failed_jobs：调用parent::failed($exception)（仅当继承Illuminate\Bus\Queueable且使用 database 驱动时才有效），更可靠的方式是直接用FailedJob::create([...]) - 或者监听
Illuminate\Queue\Events\JobFailed事件，在监听器中插入记录到failed_jobs表，并同步发告警
更推荐的做法：放弃 failed_jobs，专注 RabbitMQ 自身的失败路由
对 RabbitMQ 而言，failed_jobs 是冗余层，容易造成状态不一致。你应该信任并配置好底层消息机制：
- 启用
'reroute_failed' => true，并配好'failed_exchange'和'failed_routing_key'（如'errors.%s.failed'） - 为失败队列绑定 DLX + TTL 实现延迟重试，避免无限循环消费
- 用 RabbitMQ 管理界面或
rabbitmqctl list_queues查看*.failed队列积压，而不是查failed_jobs表 - 若仍需 Web 界面查看失败任务，可基于失败队列写个轻量后台，读取原始消息内容解析成结构化日志，比依赖
failed_jobs更准确
真正容易被忽略的是：RabbitMQ 的失败消息体是原始 JSON（含 payload、exception trace 等），而 failed_jobs 表里的 exception 字段是 Laravel 格式化后的字符串——两者堆栈细节、上下文字段都不一样。别指望它们能对上号。
