hyperf协程调度对cpu密集型任务无效，因其仅在i/o操作时触发yield，而纯计算不触发系统调用，导致协程霸占线程、单核100%但qps卡死；应剥离计算至taskworker、增加worker进程数或分片并行处理。
Hyperf 协程调度本身不直接提升 CPU 利用率；它解决的是 I/O 等待导致的 CPU 空转，但若业务逻辑纯 CPU 密集（如大量数学计算、图像处理、加密解密），协程挂起无意义，CPU 反而可能因调度开销略降效率。
为什么 Hyperf 的协程调度对 CPU 密集型任务“无效”
协程调度只在遇到 swoole_hook_flags 覆盖的 I/O 操作时生效（如 mysql_query、curl_exec、file_get_contents）。纯 PHP 循环、hash_hmac、imagecreatefromjpeg 等不触发系统调用的操作，Swoole 无法感知，也就不会 yield，协程一直霸占当前线程，其他协程得不到执行机会。
此时表现是：单核 CPU 持续 100%，但并发请求数没涨，QPS 卡死，协程数暴涨却无实际吞吐提升——这不是调度器坏了，而是它根本没被触发。
- 协程不是多线程，不自动并行 CPU 计算
-
swoole_cpu_affinity设置仅绑定 Worker 进程到 CPU 核，不影响协程内计算是否并行 - PHP 是单线程解释器，一个协程内的密集计算会阻塞整个 Worker 进程
如何识别当前瓶颈是 CPU 密集而非 I/O
用 top -Hp {pid} 查看 Worker 进程内各线程的 CPU 占用：若某个线程长期 95%+，且 swoole_server->stats() 中 coroutine_num 高但 request_count 增长缓慢，基本可判定为 CPU 瓶颈。
更准的方法是启用 opcache.file_cache 并开启 xhprof 或 blackfire，定位耗时函数是否集中在 for、array_map、json_encode 等非 I/O 函数上。
- 不要依赖
ps aux | grep php的 %CPU —— 它显示的是进程级，掩盖了协程级阻塞 -
strace -p {pid} -e trace=epoll_wait,read,write若几乎不输出，说明几乎没有 I/O 等待 - Hyperf 日志中频繁出现
Coroutine::sleep但无效果？那大概率是 sleep 被忽略（未 hook）或计算压垮了调度器
真正能提升 CPU 利用率的实操手段
必须跳出“靠协程调度榨干单核”的误区。Hyperf 场景下有效路径只有三条：
- 把 CPU 密集任务剥离到独立
Process或TaskWorker：用$server->task()提交，避免阻塞协程调度器；返回结果用onTask回调处理 - 启用多 Worker 进程：通过
worker_num配置（如设为 CPU 核数），让不同 Worker 并行跑不同请求；注意max_coroutine应略高于平均并发，避免协程创建失败 - 对可并行计算做分片 +
Parallel：比如批量处理 1000 条数据，拆成 10 组每组 100 条，用Hyperf\Utils\Parallel启动 10 个协程——但前提是这些计算不共享状态，且每组耗时不悬殊
示例关键代码：
$parallel = new Parallel(4); // 最多同时跑 4 个子任务
foreach (array_chunk($data, 100) as $chunk) {
$parallel->add(function () use ($chunk) {
return array_map(fn($x) => hash_hmac('sha256', $x, 'key'), $chunk);
});
}
$results = $parallel->wait(); // 阻塞等待全部完成，但期间其他协程仍可运行
最容易被忽略的调度器隐性损耗
协程调度器本身有开销：每次 yield/resume 约 50–100ns，看似 negligible，但当单请求内发起上千次微小 I/O（如循环查 Redis 单 key），调度频次爆炸，反而拖慢整体吞吐。
此时应优先合并操作：$redis->mget(['k1','k2','k3']) 替代三次 $redis->get()；用 Hyperf\DbConnection::transaction() 批量写库；避免在协程里高频调用 Co::sleep(0) “让出控制权”——这毫无必要，还增加调度抖动。
真正的高 CPU 利用率，来自合理分配：Worker 进程吃满物理核，协程专注等 I/O，计算任务下沉到进程/外部服务。混淆 Reactor、Worker、协程调度三者的职责，是绝大多数性能调优失败的起点。
