LaravelAPI如何做异步处理_LaravelAPI异步任务队列实现【方法】-Laravel-PHP中文网

laravel api中dispatch任务不生效是因为默认队列驱动为sync，导致同步阻塞；需改用redis/database等异步驱动并运行queue:work，同时注意重试机制、状态追踪及dispatchnow的陷阱。

laravelapi如何做异步处理_laravelapi异步任务队列实现【方法】

为什么 Laravel API 直接 dispatch 任务不生效

因为默认队列驱动是 sync，任务不会真正异步，而是在当前请求中同步执行——你以为扔进队列了，其实只是换个地方阻塞。

检查 config/queue.php 中 default 配置，生产环境绝不能是 'sync'
运行 php artisan queue:work 前，先确认 QUEUE_CONNECTION 环境变量或配置已指向 redis / database / beanstalkd
API 路由里调用 dispatch(new SendEmailJob()) 后，立刻返回响应，不代表任务已执行；要查 jobs 表（database 驱动）或 Redis key（redis 驱动）才能验证是否入队成功

Laravel 10+ 中 job 失败后不重试的常见原因

不是配置没写，而是 Laravel 默认只对特定异常重试——比如 Exception 不触发重试，但 RuntimeException 会。

tries 属性只对「未被捕获的、非 Exception 子类」异常起作用；自定义异常需显式继承 ShouldBeQueued 或手动 throw new RuntimeException()
使用 php artisan queue:work --stop-when-empty 时，job 失败后进程退出，根本没机会重试；应改用 php artisan queue:work --tries=3
Redis 驱动下，若 retry_after（如 90 秒）太短，job 执行超时会被丢进 failed_jobs 表，而不是重试；建议设为最长可能执行时间的 2 倍

API 返回任务 ID 后如何查执行状态

Laravel 没内置任务状态追踪，得自己存 + 查——别指望 job->id 能直接当查询键用。

Laravel 13.2.0

PHP中文网提供Laravel 13.2.0版本下载，Laravel框架是基于 PHP 8.3+ 的高性能框架，官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索，支持属性驱动开发与队列路由，大幅提升开发效率。相比旧版，13.2.0 优化了缓存 TTL 管理与实时通信，无需 Redis 即可横向扩展。作为现代 Web 开发首选，它兼顾安全与极速体验，助您快速构建企业级应用。

下载

在 job 的 handle() 开头写 cache()->set("job_status_{$this->uuid}", 'running', 3600)，结尾改为 'success' 或 'failed'
不要用 $job->id：它是队列系统生成的内部 ID（如 Redis 的 queues:default:0 下的索引），对外无意义；改用 Str::uuid() 生成业务 ID 并传入 job 构造函数
前端轮询时，路径建议设计为 GET /api/jobs/{uuid}/status，后端直接 cache()->get("job_status_{$uuid}")，别查数据库

dispatchNow 和 dispatch 的性能陷阱

dispatchNow() 看似“快”，实则绕过队列、关闭所有中间件（如日志、事务）、无法失败重试——它适合调试，不适合生产 API。

API 接口里混用两者会导致行为不一致：一个走队列，一个直奔 handle()，事务边界、DB 连接、日志上下文全乱
dispatch() 在测试环境下仍走 sync 驱动，所以 dispatchNow() 在测试中表现和线上不同；统一用 dispatch() + 切换 QUEUE_CONNECTION=sync 测试逻辑更可靠
高并发 API 下，dispatch() 入队耗时约 0.5–2ms（Redis），而 dispatchNow() 执行耗时若超 100ms，会拖垮整个请求；异步的意义不在“快”，而在“不卡主流程”

真正难的不是把 job 扔进队列，而是让每个 job 有独立上下文、可追溯、失败不静默、重试不重复——这些得靠 cache 键设计、uuid 透传、和失败表结构配合，不是开个 queue:work 就完事。