协程阻塞导致CPU 100%但无报错，本质是纯CPU计算独占线程使调度器失效；关键判断为swoole_get_local_cid()返回-1或Coroutine::listCoroutines()为空；需禁用同步调用、循环中插入Co::sleep让出控制权。
协程阻塞导致CPU 100%但无报错
Hyperf 协程里跑纯 CPU 计算（比如循环加密、JSON 解析、数组遍历），调度器无法切换，线程被独占，接口超时、新请求卡住、CPU 占用飙到 100%，但日志安静得像没出事——这是最典型的隐性阻塞。
关键判断点：swoole_get_local_cid() 返回 -1 或 Coroutine::listCoroutines() 返回空数组，说明协程上下文已丢失，调度器离线。
- 检查所有
for/while循环是否含 IO 操作；若没有，就是风险点 - 禁用
sleep()、usleep()、file_get_contents()、curl_exec()等同步调用——它们在协程里会直接阻塞线程 - 用
Co::sleep(0.001)替代sleep(1)，强制让出控制权 - 对长循环加计数器 +
if ($i % 100 === 0) Co::sleep(0.0001);，避免单次执行过久
协程快照定位 WAITING 状态协程
进程响应变慢、请求堆积但 CPU 不高，大概率是某个协程卡在 I/O 等待上，比如 Redis 连接超时、MySQL 查询未返回、HTTP 客户端 hang 住。此时必须看真实协程状态，不能只盯日志。
执行 kill -USR1 <worker_pid> 会生成快照到 /tmp/swoole-coroutine-*.log，但更可控的是代码内诊断：
- 在异常中间件或定时任务里插入：
Coroutine::listCoroutines()获取全部 CID - 对每个 CID 调用
Coroutine::getStatus($cid)，筛选出SWOOLE_CORO_WAITING - 对这些协程调用
Coroutine::getBackTrace($cid, 0, 20)，重点看最后一帧是不是stream_socket_client、socket_read或redisConnect - 注意：
getBackTrace()第二个参数必须是0，否则跳过关键调用层
Redis/DB 连接池泄漏引发的假性阻塞
表面看是“协程不动了”，实际是连接池耗尽，后续协程全卡在 wait timeout 上，表现为任务不消费、接口延迟上涨、task_wait_queue_len 持续增长但 tasking_num == 0。
这不是代码逻辑问题，而是资源没归还：
- 查当前 ESTABLISHED 连接数：
ss -s | grep ESTAB，对比redis.php中pool.max_connections - 所有
$redis->pipeline()或$redis->multi()必须配finally块，显式调用$redis->reset()（Hyperf 3.0+）或unset($redis) - DB 查询避免
get()/all()，改用cursor()或原生fetch()，防止 PDO 缓冲整表加载 - 不要在协程里复用同一个
Redis实例变量跨多次调用——它绑定当前协程上下文，泄漏后连接不释放
异步队列消费者不工作却无日志
任务投进 Redis 后石沉大海，ps aux 查不到 async-queue:consume 进程，或进程存在但 handle() 根本没触发，连日志都不打——这不是队列配置错，而是消费者压根没拉起或启动即崩。
- 确认
config/autoload/processes.php明确注册了Hyperf\AsyncQueue\Process\ConsumerProcess::class - 启动时控制台必须输出
Process[AsyncQueueProcess] start，没有就说明注册失败 - 手动运行
php bin/hyperf.php async-queue:consume --verbose，看是否立即抛出Connection refused或Class not found - 检查
config/autoload/async_queue.php中processes> 0，且对应 Redis 连接池已配置并能ping()通 - Job 类必须继承
Hyperf\AsyncQueue\Job，构造函数参数必须可序列化（不能传Closure、PDO、resource）
