Laravel怎么使用队列_Laravel Queue异步任务教程【优化】

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，出队列再查库。其他任何捷径，后面都会花更多时间补洞。