payload字段中必看data.command（任务类全名）、data.attempts（已重试次数）、data.maxTries（最大重试数），三者共同决定反序列化能否成功及失败根因。
反序列化失败时 payload 字段里藏了什么关键信息
直接查 failed_jobs 表的 payload 字段，别跳过它。这个 JSON 字符串里有三个必看键：data.command（任务类全名）、data.attempts（已重试次数）、data.maxTries（最大重试数）。如果 data.command 是 "App\Jobs\SendEmail"，但实际类文件已删或命名空间改成了 App\Tasks\SendEmail，反序列化必然失败，报错类似 Class "AppJobsSendEmail" not found。
常见翻车点：
-
use没写全，比如类里写了new EmailService()却没use AppServicesEmailService，反序列化时找不到类 - 任务类用了相对命名空间（如
namespace Jobs;），但payload里存的是绝对路径，导致类加载失败 -
payload被截断（MySQL TEXT 字段默认 65535 字节），尤其含大附件或长数组时，JSON 解析直接报unserialize(): Error at offset
RabbitMQ 场景下 Job 类必须满足的序列化约束
Laravel 默认用 PHP 的 serialize() 存任务对象，而 RabbitMQ 本身不参与序列化逻辑——它只负责传原始字节流。真正出问题的地方在 Laravel 反序列化时：它会尝试重建整个对象，包括构造函数参数和属性。
以下类型不能出现在 __construct() 或 public 属性中：
-
Request实例（含$request->all()这种动态数据） - 闭包（
function() { ... }） - 数据库连接、Redis 客户端等资源句柄
- 未声明
public的属性（反序列化后为null，但构造函数可能依赖它）
正确做法是把运行时依赖延迟到 handle() 里获取，比如把 $this->user = auth()->user() 拆成 $user = auth()->user() 放在 handle() 开头，而不是塞进构造函数。
怎么验证 payload 是否能被当前环境反序列化
别等重试才暴露问题。人工模拟一次反序列化流程：
// 在 tinker 或临时命令里执行
$payload = DB::table('failed_jobs')->where('id', 123)->value('payload');
$data = json_decode($payload, true);
$command = $data['data']['command'] ?? null;
if (class_exists($command)) {
$job = unserialize(base64_decode($data['data']['job']));
dump($job); // 看是否报错
} else {
Log::error("Class not found: {$command}");
}
如果报 unserialize(): Error at offset，说明 payload 已损坏；如果报 Class not found 或 Call to undefined method，说明类定义或依赖有问题。
自定义序列化逻辑：绕过 PHP serialize 的硬伤
如果你的任务确实需要传 Request 或 Closure，就得放弃 Laravel 默认的 serialize()，改用 JSON + 手动重建。
在 Job 类里加两个方法：
public function __serialize(): array
{
return [
'email' => $this->email,
'template' => $this->template,
'attempts' => $this->attempts,
];
}
public function __unserialize(array $data): void
{
$this->email = $data['email'];
$this->template = $data['template'];
$this->attempts = $data['attempts'] ?? 0;
}
注意：__serialize() 和 __unserialize() 是 PHP 7.4+ 原生支持的魔术方法，Laravel 9+ 队列处理器能识别它们。这样既避免了不可序列化对象的问题，又保留了参数结构化能力。
最后提醒一句：RabbitMQ 本身不校验 payload 格式，所有反序列化失败都发生在 Laravel 消费端。所以部署前务必在目标环境跑一遍 php artisan queue:work --once，别只在本地测。
