think-queue默认同步执行，必须显式配置redis驱动、填全host/port/select/password等参数，启用常驻消费者进程并规范任务投递（只传id）、设置合理retry_after与失败处理机制，否则无法真正异步。
ThinkPHP 用 think-queue 配 Redis 跑异步任务，关键不是“装上就能用”，而是配置对、连接稳、投递轻、消费常驻。Redis 是最常用也最容易踩坑的组合，下面直说实操要点。
基础配置要填全、对得准
在 config/queue.php 中必须明确声明 Redis 连接参数，不能依赖默认值或环境变量自动覆盖：
-
driver 类型写
'type' => 'redis'，不是'driver'（旧版写法已不兼容） -
database 索引用
'select'字段，且值为整数（如1），不能是字符串"1" -
密码为空时显式写
''，留空或省略会导致连接失败 -
加
'prefix' => 'tp6:queue:'避免多项目共用 Redis 时键名冲突 -
'retry_after' >= 任务最长执行时间，比如短信发送通常 30 秒内完成，这里建议设为90，防止误判失败重发
任务投递别带大对象，只传 ID
控制器里推送任务时，切忌把完整模型或数组序列化进去——Redis 存的是字符串，大体积数据会拖慢队列吞吐，还可能触发 PHP 序列化限制：
- ✅ 正确：只传业务主键，逻辑下沉到任务类中处理
Queue::push(new SendSmsJob($userId)); - ❌ 错误：查库+序列化整个对象
Queue::push(new SendSmsJob(User::find($userId))); // 内存爆炸风险高 - 延迟任务用
delay参数，单位是秒：Queue::later(60, new NotifyUserJob($orderId));
消费者不能只靠 php think queue:listen
该命令适合开发调试，但生产环境跑万级并发时，它每处理一个任务就启一次进程，开销大、易堆积、无监控。应升级为：
-
常驻协程消费者：用 Swoole +
brpop阻塞监听，CPU 占用低、响应快 -
进程池模式：配合 Supervisor 启多个
queue:work --daemon实例，每个固定处理 N 个任务后重启，防内存泄漏 -
手动指定队列名，避免混跑：
php think queue:work --queue=sms,default --sleep=3 --max-jobs=1000
失败任务要有落库+告警机制
默认失败任务只打日志，线上出问题很难追溯。务必启用失败表并配好：
- 在
config/queue.php的'failed'段启用数据库存储：'type' => 'database', 'table' => 'failed_jobs' - 提前运行迁移命令建表：
php think migrate:create CreateFailedJobsTable（或手动建） - 每天定时清理超 7 天的失败记录，同时对接企业微信/钉钉机器人发告警
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
