Hyperf异步队列任务不消费的根本原因是消费者进程未启动或Redis连接池异常：需确认processes.php注册ConsumerProcess、async_queue.php中processes>0、Redis连接池通且max_connections足够，同时Job类必须继承AsyncQueue\Job且参数可序列化，handle()内须全协程调用。
Hyperf异步队列任务提交后一直卡在Redis里不消费，接口返回快但后台逻辑没跑，订单超时取消失效、邮件发不出、日志里连handle()调用痕迹都没有——这不是代码写错了，而是消费者进程根本没起来或被阻断了。
确认消费者进程是否真正拉起
第一步：执行php bin/hyperf.php start后，紧盯控制台输出，必须看到Process[AsyncQueueProcess] start或类似标识；若只显示Worker启动成功却无Consumer字样，说明消费者未注册。
第二步：检查config/autoload/processes.php是否明确注册了消费者进程类：【Hyperf\AsyncQueue\Process\ConsumerProcess::class】必须出现在返回数组中，缺一个字都不行。
第三步：运行ps aux | grep hyperf，核对实际进程数。如果config/autoload/async_queue.php中'processes' => 2，但ps只查到1个Consumer进程，说明其中一个异常退出——此时立刻看runtime/logs/hyperf.log末尾是否有abnormal exit报错。
验证Redis连接池是否就绪
方法一：直接在控制器里写一段测试代码，调用$this->container->get(\Hyperf\Contract\ConnectionInterface::class)->ping()，返回+PONG才算通；返回false或抛异常，说明Redis连接池压根没配好。
方法二：检查config/autoload/redis.php中default池的host、port、auth是否与.env一致，特别注意auth为空时不能写null，要删掉该键或设为空字符串。
方法三：用redis-cli -h {host} -p {port} -a {auth} ping手动连一次。如果命令行能通但Hyperf不通，大概率是redis.php里pool.max_connections设得太小，高并发时连接被占满，新任务投递时直接卡在序列化环节——这时日志里不会报错，但task_wait_queue_len会持续上涨。
检查任务类是否满足硬性约束
第一步：确认Job类继承的是Hyperf\AsyncQueue\Job，不是Hyperf\Task\Task或随便写的普通类；父类不对，Consumer进程根本识别不了这个任务。
第二步：检查构造函数参数是否全部可序列化。传入Closure、PDO实例、resource会导致serialize()失败且静默丢弃任务——日志里只有serialize(): __sleep should return an array这种提示，不细看根本发现不了。
第三步：打开config/autoload/async_queue.php，确认'driver'指向的是Hyperf\AsyncQueue\Driver\RedisDriver::class，而不是留空或拼错成RedisDrier这种低级错误。
定位handle()执行卡点
① 在handle()开头加一行file_put_contents('/tmp/handle_start.log', date('Y-m-d H:i:s') . " task_id: {$this->id}\n", FILE_APPEND);，然后投递任务。如果文件没内容，说明任务根本没被消费；如果有时间戳但没后续，说明卡在某处。
② 把handle()里的所有sleep()、curl_exec()、file_get_contents()全部换成协程版：Co::sleep(1)、Http\Client::post()、Co::readFile()——混用同步阻塞调用会让整个Consumer协程挂死，后续所有任务排队等它释放。
③ 检查config/autoload/async_queue.php中的'handle_timeout'是否过短。比如任务正常要8秒，你设成5秒，就会被强制中断且进失败队列，但日志里只记timeout，不打印堆栈。
方法二：启用Hyperf官方日志协程上下文，在handle()里打日志时加上Co::pid()和Coroutine::id()，对比多个任务的日志时间戳和协程ID，能快速判断是单个协程卡死还是全队列停滞。
