Laravel队列处理耗时任务全解析

Laravel队列并非开箱即用的“异步魔法”，而是需要精准配置与深度理解的后台任务处理机制：dispatch()后任务不执行，往往是因为默认未启动消费者进程或误配为sync同步驱动；queue:work必须配合Supervisor管理，并通过--max-jobs或--max-time定期重启以规避内存泄漏；任务中严禁传递Eloquent模型实例，须在handle()内按ID重新查询以确保数据新鲜；Redis驱动下还需主动实现幂等性（如uniqueFor+业务去重），而非依赖队列保证“恰好一次”。真正高效可靠的异步处理，始于对生命周期、序列化边界和分布式特性的清醒认知。

为什么 dispatch() 后任务没执行？

不是代码没写对，而是 Laravel 队列默认不自动运行——它只是把任务塞进队列存储（Redis/Database），等着你手动启动消费者进程。常见现象是调用 dispatch() 没报错、日志里也看不到失败，但邮件没发、文件没生成、第三方 API 没调用。

• 检查 QUEUE_CONNECTION 环境变量是否设为 sync（开发时默认值）：这是同步模式，会立刻执行，但**不是异步**；要真异步，得改成 redis 或 database
• 确认已运行 php artisan queue:work（单次）或 php artisan queue:listen（旧版，不推荐），且该进程没被意外终止（比如终端关闭、Supervisor 未配置）
• 如果用 database 驱动，确保 jobs 表存在并可写；用 redis 则需 phpredis 扩展启用，且 Redis 连接正常

queue:work 和 queue:listen 到底用哪个？

queue:listen 已废弃（Laravel 5.7+ 起移除），现在只用 queue:work。但它有关键行为差异：默认情况下，queue:work 启动后会复用同一个 Laravel 应用实例处理所有任务，导致内存泄漏、配置未刷新、数据库连接超时等问题。

• 加 --once 参数让它每处理一个任务就退出：适合调试或低频任务，但频繁启停开销大
• 生产环境必须配 --max-jobs=100 或 --max-time=3600，强制进程定期重启，避免内存累积
• 务必配合 Supervisor 管理进程，不能裸跑 queue:work；否则崩溃后无人拉起

任务类里该不该在 handle() 里写 DB 查询？

可以写，但要注意模型状态和连接生命周期。队列任务是“延迟执行的闭包”，它序列化时只存参数，不存整个对象实例。所以你在 dispatch 时传的是 ID，不是 Eloquent 模型本身。

• 错误写法：$user = $this->user;（假设 $this->user 是模型实例）→ 反序列化失败或数据过期
• 正确写法：在 handle() 里用 ID 查库，如 $user = User::find($this->userId);
• 如果任务需要大量关联数据，考虑在 dispatch 前预取关键字段（如 JSON 字符串），避免 handle 中 N+1 查询
• 注意事务：队列任务不在原请求事务内，DB::transaction 不会跨进程生效

Redis 驱动下任务重复执行怎么防？

Redis 本身不保证“恰好一次”，网络分区或 worker 崩溃未及时 ack，会导致任务被重新入队。Laravel 默认重试 3 次（$tries = 3），但业务上仍可能出问题。

• 给任务类加 public $uniqueFor = 3600;（秒），配合 uniqueId() 方法，防止相同参数任务短时间重复入队
• 关键操作加幂等判断：比如发短信前查 sms_logs 表是否已有同 order_id 记录
• 不要依赖 failed() 方法做补偿逻辑——它只在重试耗尽后触发，中间失败不会进这里
• Redis 的 blocking pop 特性让 queue:work 在无任务时休眠，别误以为卡死

队列不是开关一开就自动变快的魔法，它把“执行时机”从请求周期里剥离开，但同时也把错误排查从单次 HTTP 生命周期，拉长到了后台进程 + 存储 + 网络的链路里。最常被忽略的，是忘记给 queue:work 加内存/时间限制，以及把模型实例直接塞进构造函数。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。