laravel队列不执行主因是queue_connection与queue:work驱动不匹配，需确保二者一致；任务类须显式声明tries和backoff；redis驱动应设block_for=>null并配置prefix；模型传id而非实例，避免序列化问题。
队列没跑起来？先确认 QUEUE_CONNECTION 和 php artisan queue:work 是否匹配
Laravel 队列不执行，八成卡在连接配置和工作进程不一致上。比如 .env 里写的是 QUEUE_CONNECTION=redis，但你却用 php artisan queue:work database 启动——它只会监听 database 连接，对 redis 里的任务完全无感。
-
QUEUE_CONNECTION是全局默认，决定dispatch()把任务扔进哪个驱动；queue:work的参数（如redis）才是实际监听的驱动，二者必须一致 - 开发时别依赖
php artisan serve自带的热重载：队列工作进程是常驻内存的，改了代码必须手动重启queue:work - 用
php artisan queue:work --verbose能看到实时日志，包括“Processing”“Failed”等关键状态，比盲猜快得多
任务失败后自动重试，但 tries 和 backoff 很容易配错
默认任务只试一次就进 failed_jobs 表，但多数场景需要重试。关键是理解 tries 控制总次数，backoff 控制每次失败后的等待秒数，且两者必须在任务类里显式声明，环境变量或配置文件里设无效。
- 在任务类顶部加
public $tries = 3;和public $backoff = 5;：第一次失败等 5 秒，第二次等 10 秒（Laravel 默认指数退避），第三次失败才进失败表 - 如果用了
retryUntil()，它会覆盖tries，但返回时间必须是DateTimeInterface实例，写now()->addSeconds(30)没问题，写字符串"+30 seconds"会静默失效 - 数据库驱动下，
failed_jobs表的exception字段只存前 65535 字节，超长堆栈会被截断——查不到完整错误时，优先看日志文件而非这张表
Redis 驱动下 php artisan queue:work 卡住不动？检查 block_for 和连接复用
用 Redis 时，queue:work 常出现“看起来在运行，但任务就是不消费”，大概率是 Laravel 的 block_for 参数（默认 5 秒）和 Redis 连接池行为叠加导致的假死。
- 在
config/queue.php的redis配置里加'block_for' => null：让BRPOP不设超时，有任务立刻响应，避免轮询空转 - 确保
redis连接配置中的options包含'prefix' => 'queues:'，否则多个项目共用 Redis 时会互相干扰 - 不要在任务里用
DB::transaction()包裹整个逻辑：队列进程是长生命周期的，事务连接可能被复用污染，应只在真正需要原子性的代码块内开启
从同步切异步时，$this->user 这类 Eloquent 模型属性会丢失
把原本在控制器里直接调用的方法挪进队列任务后，常见报错是 Call to a member function xxx() on null——因为模型实例不能被序列化进队列，只存了 ID，反序列化时不会自动重新查询。
- 别在构造函数里直接传
$user实例，改传$user->id，然后在handle()里用User::findOrFail($this->userId)重新加载 - 如果必须传模型，用
serializeModels属性（Laravel 9.2+）：protected $serializeModels = true;，但注意这会增加序列化体积，且要求模型没挂载闭包或资源句柄 - 关联数据（如
$user->posts）不会随模型一起加载，必须在handle()中显式调用$user->load('posts')，不能依赖构造时的状态
队列不是万能胶水，模型、请求、会话这些上下文敏感的东西，一粘就掉。最稳的方式永远是：进队列只传 ID，出队列再查库。其他任何捷径，后面都会花更多时间补洞。
