确保HTTP客户端真正非阻塞，需三步验证：一、绑定Hyperf\Guzzle\ClientFactory::class；二、必须用$this->clientFactory->create()而非new GuzzleHttp\Client()；三、压测时coroutine_num涨而request_count不增即未协程化。
Hyperf 3.1 面试常问：如何确保 HTTP 客户端在协程环境下真正非阻塞、不拖垮整个 Worker 进程？关键不是“用了 Guzzle”，而是客户端是否走协程 IO 路径、连接是否复用、超时是否由协程层接管——错配任意一环，高并发下照样卡死。
确认客户端是否启用协程化
第一步：检查 config/autoload/dependencies.php 中是否已绑定协程版 Guzzle 客户端实例：
【必须存在且不可注释】 'GuzzleHttp\Client' => \Hyperf\Guzzle\ClientFactory::class
第二步：在控制器中注入并使用时，确认构造方式：
✅ 正确写法：$client = $this->clientFactory->create(['timeout' => 3.0]);
❌ 错误写法：new \GuzzleHttp\Client(['timeout' => 3.0]) —— 此方式绕过 Hyperf 协程封装，直接调用同步 Guzzle，会阻塞协程调度。
第三步：验证实际行为——压测时执行 swoole_server->stats()，若 coroutine_num 持续上涨但 request_count 几乎不动，说明客户端未协程化，正在同步等待 socket 返回。
强制启用连接池 + 设置合理超时
方法一：配置连接池（推荐）
编辑 config/autoload/http_client.php，启用连接池并设置最小/最大连接数：
'pool' => [
'min_connections' => 5,
'max_connections' => 30,
'connect_timeout' => 3.0,
'wait_timeout' => 3.0,
'heartbeat' => -1,
],
【max_connections 不可设为 0 或负数，否则连接池失效，退化为单连接串行】
方法二：运行时动态指定超时（仅限临时调试）
$client->get('https://api.example.com', ['timeout' => 2.5]);
⚠️ 注意：此 timeout 仅作用于本次请求，且必须 ≤ connect_timeout + read_timeout，否则被底层 Swoole 协程客户端截断。
规避阻塞式 IO 的三大雷区
第一步：禁用所有隐性同步磁盘 IO
关闭 opcache.file_cache；日志 Handler 替换为 Hyperf\Logger\Handler\StdoutHandler 或协程安全的异步 FileHandler；配置文件加载避免使用 file_get_contents() 等同步读取。
第二步：MySQL 查询必须带索引 + 显式超时
DB::select('SELECT * FROM orders WHERE user_id = ? AND status = ?', [$uid, 'pending']) → 若 user_id 无索引，该查询将阻塞整个协程，Worker 进程停摆；必须配合 EXPLAIN 验证执行计划，且在 query() 前加 DB::connection()->setTimeout(2.0)。
第三步：Redis Pipeline 必须显式 execute()
$pipe = make(Hyperf\Redis\Pipeline::class, ['redis' => $this->redis]);
$pipe->get('key1');
$pipe->get('key2');
$result = $pipe->execute();
【漏掉 $pipe->execute() 将导致命令永远滞留在内存，不发往 Redis，也不报错】
