hyperf能显著加速i/o密集型请求，前提是全链路协程化：http用hyperf/http-client、db用hyperf/database协程驱动、redis用hyperf/redis、文件操作改用协程api，任一环节未协程化都将导致调度失效、性能退化。
Hyperf 能显著加速 I/O 密集型慢请求，但前提是协程真正“跑起来”——不是加了 Coroutine::create 就算协程化，而是整个调用链路必须全程协程安全。否则极易退化成伪异步，甚至比 FPM 更卡。
为什么传统 FPM 在 I/O 慢请求里特别吃亏
PHP-FPM 每个请求独占一个进程，遇到 curl_exec、PDO::query 或 file_get_contents 这类同步阻塞操作时，进程直接挂起等待响应。500ms 的数据库查询或第三方 API 延迟，意味着这个进程 500ms 内什么也不干，只耗内存、占连接、堵队列。
常见表现包括：
- QPS 上不去，但 CPU 使用率很低（大量进程在
Sleeping状态） - MySQL 连接数频繁打满，报错
Too many connections - 日志里大量超时，但服务端没报错，只是“等不到返回”
Hyperf 协程加速的关键落地点
Hyperf 不是魔法开关，它靠 Swoole 的协程运行时接管所有标准 I/O 操作。但仅当这些操作被协程版驱动覆盖时，才能触发自动切换。否则仍是同步阻塞。
必须确认以下几处已替换为协程安全实现：
- HTTP 请求：用
Hyperf\HttpClient\Client，别用cURL或file_get_contents - 数据库：用
Hyperf\DbConnection+swoole_mysql协程驱动，禁用 PDO 长连接直连 - Redis：用
Hyperf\Redis\Redis，底层走swoole_redis，不是predis或phpredis同步扩展 - 文件读写：避免
fopen/file_get_contents，改用Co\FileSystem或异步写入任务（TaskWorker）
漏掉任意一项，都可能让整条请求链卡在某一处，其他协程全被拖住。
协程调度失效的典型信号与自查方式
你以为协程在跑，其实调度器早就“失联”了。最常踩的坑是混用了同步和协程组件，导致调度器无法感知阻塞点。
快速判断是否真协程化：
- 看日志里有没有
WARNING: Coroutine xxx is blocked（Swoole 开启hook_flags后可捕获） - 用
swoole_get_local_cid()在不同调用点打印协程 ID：如果 HTTP 请求前后 CID 不变，但 DB 查询后变了，说明 DB 层没走协程 - 压测时观察
coroutine_num：持续低于worker_num * 1000，大概率有协程被长期占用未释放
尤其注意 Composer 包里的 SDK —— 百度翻译、微信支付等官方 SDK 多数仍是同步封装，必须自行包装成协程调用，或改用 Hyperf\Guzzle 等适配器。
慢接口改造的最小可行路径
不追求一步到位，先让最慢的那 1–2 个接口真正协程化，验证效果后再铺开。
以一个含远程 API 调用 + 数据库写入的慢接口为例：
- 第一步：把
curl替换为$this->client->get($url)，确保Hyperf\HttpClient已启用 - 第二步：检查数据库操作是否在
DbConnection实例上调用，而不是 new PDO；确认 config/autoload/databases.php 中driver是mysql（非pdo_mysql） - 第三步：在 Controller 方法上加
@Inject注入协程组件，**不要**在方法体内 new 类或调用静态函数（会绕过 DI 容器，失去协程代理） - 第四步：压测对比，重点看 P95 响应时间与 worker 进程存活率，而非单纯吞吐量
协程的优势不在峰值 QPS，而在稳定高并发下的资源利用率。一个 2 核机器跑满 1000 QPS 的 Hyperf 服务，内存占用通常不到同负载 FPM 的 1/3 —— 但这只在 I/O 真正“放手”让出控制权时才成立。
