Hyperf请求超时需分清连接建立、响应读取、连接池耗尽三类超时，对应调整Guzzle分层超时、Redis/MySQL连接池参数，并通过telnet/curl/Swoole状态等逐层排查。
Hyperf 请求超时不是单一配置能解决的问题，而是涉及网络、协程调度、客户端组件（Guzzle/cURL）、连接池、中间件等多层协同的结果。处理的关键是分清“超时类型”，再对应调整配置或架构。
一、先区分三类典型超时表现
不明确超时性质就改配置，容易白忙活：
-
连接建立超时（Connect Timeout）：请求发不出去，报
ConnectException或Connection refused，常见于服务未启动、防火墙拦截、DNS 解析失败、Swoole 层连接参数过短； -
响应读取超时（Read Timeout）：TCP 连接已建立，但服务端迟迟不返回完整响应，表现为卡住几秒后抛出
RequestException，多因业务逻辑阻塞、下游依赖慢、Redis/MySQL 响应延迟； -
连接池耗尽超时（Pool Exhausted）：报
Too many connections或日志出现wait timeout，本质是并发请求数超过连接池容量，协程在等空闲连接，而非网络或业务慢。
二、Guzzle 客户端超时要分层配
Hyperf 的 Guzzle 默认走协程化 CoroutineHandler，但超时必须显式分层设置，否则只设 timeout 很难精准控制：
-
connect_timeout：控制 DNS 解析 + TCP 握手耗时，建议设为 2–3 秒； -
read_timeout：控制从连接建立到收到完整响应的时间，建议略小于总超时，如总超时 10 秒，这里设 8 秒； -
timeout：总生命周期上限，含重试时间，设为 10–15 秒 较稳妥； -
swoole.connect_timeout和swoole.timeout：Swoole 底层 HTTP 客户端的独立超时，需同步设置，否则协程层可能不生效； - 重试策略别滥用：
retries: 2, delay: 100（毫秒）比默认的 1 次更实用，但避免无脑设高重试次数，会放大下游压力。
三、Redis/MySQL 连接池超时要调准参数
连接池本身不是“越大多好”，关键在匹配业务节奏：
- MySQL 推荐
pool.max_connections设为 50–100（非默认 10），pool.connect_timeout缩短至 3–5 秒，避免协程长时间卡在建连； - Redis 同理，
max_connections至少 20+，connect_timeout建议 2.0，wait_timeout不宜低于 3.0，防止连接空闲回收后重连开销； - 注意
min_connections别设太小（如 1），冷启动时大量协程争抢首连接，易引发雪崩式等待。
四、排查链路要从外到内逐层验证
别一上来就翻代码，先用基础命令快速定位瓶颈层：
- 用
telnet 服务IP 端口或nc -zv IP port看能否建连——不通就是网络或服务未启； - 用
curl -v --connect-timeout 3 --max-time 10 URL模拟请求，观察卡在Connected还是Downloading阶段； - 查 Swoole 进程状态：
php bin/hyperf.php server:info看 worker 数、协程数是否打满； - 查数据库连接数：
SHOW STATUS LIKE 'Threads_connected';对比max_connections是否接近阈值； - 开启 Hyperf 日志中的
guzzle和redischannel，看超时前最后一条日志落在哪一层。
