hyperf连接池配置需协同优化：wait_timeout宜设2.0～5.0，max_connections应按峰值qps×平均耗时加余量估算，断线重连失效多因连接泄漏或协程上下文污染，min_connections、max_idle_time等参数须联动调整。
Hyperf 连接池不是“设了就完事”的配置项，wait_timeout 过小会直接让协程失败，过大则掩盖真实瓶颈；max_connections 低于峰值并发 × 平均耗时，必然触发 WaitTimeoutException；而断线重连失效，往往不是 Redis 或 MySQL 自身断开，而是协程上下文污染或连接未归还导致的连锁假象。
pool.wait_timeout 设多少才合理？
这个值不是越小越好，也不是越大越好，它决定协程在连接池里“排队等连接”的最长容忍时间。
-
wait_timeout小于 1.0（比如 0.1）：协程还没来得及等到空闲连接就被强制抛出Hyperf\Pool\Exception\WaitTimeoutException，日志里满屏 “wait timeout”，但实际连接池可能只是瞬时抖动 -
wait_timeout大于 8.0（比如 15.0）：请求会长时间卡住，掩盖了max_connections不足、pipeline 泄漏或 MySQL gone away 导致的连接上下文损坏等真正问题 - 推荐设为
2.0～5.0：既能给连接释放留出缓冲（比如事务/管道执行耗时波动），又能在异常堆积时快速失败，便于定位 - 验证方式：用
swoole_get_local_socket_count()或ss -s | grep ESTAB观察实际 ESTABLISHED 连接数是否长期贴近max_connections，如果是，说明不是超时设置问题，而是池子真不够用
max_connections 算不准？看 QPS × 耗时再加余量
很多人凭感觉设 max_connections，结果一上量就崩。它本质是「同时活跃连接数」的上限，必须从实际负载反推。
- 粗略公式：
max_connections ≈ 峰值 QPS × 平均单次 DB/Redis 操作耗时（秒） - 举例：接口峰值 120 QPS，MySQL 查询平均耗时 0.08s → 理论需 9.6 个连接，但必须留余量 → 建议设为
30～50 - Redis 更激进：若大量使用
pipeline()或multi()，每个调用可能独占连接直到exec()，此时要按「pipeline 内命令数 × 并发协程数」预估，不能只看 QPS - 别忽略定时任务和 WebSocket 长连接：它们常驻协程可能长期持有连接，容易被漏算
断线重连为什么没生效？先查是不是连接根本没归还
所谓“断线重连失败”，90% 场景下不是网络问题，而是连接泄漏导致新协程压根拿不到连接去触发重连逻辑。
- 典型泄漏点：
$redis->pipeline()或$redis->multi()后未调exec()，或中间抛异常跳出了 try 块 → 连接被当前协程锁死，直到协程退出（可能几分钟后） - 验证方法：在疑似泄漏位置加日志，检查
Context::has($redis->getContextKey())返回true但后续无exec()调用 → 基本确认泄漏 - 安全写法：用 Hyperf 3.1+ 提供的
withPipeline()，它内部包了 try/finally 自动 release；老版本必须手写try { ... } finally { $pipe->exec(); } - MySQL gone away 后 Redis 也连不上？大概率是同一个协程里 MySQL 异常未捕获，事务回滚失败，导致协程上下文损坏，Redis 客户端底层
Co\Redis直接报Connection reset by peer—— 此时重连配置再全也没用
连接池配置别只改 max_connections，这几个参数联动才关键
min_connections、max_idle_time、connect_timeout 和 max_connections 是咬合工作的，单独调一个容易引发新问题。
-
min_connections设太低（如默认1）：冷启动或低峰期连接数锐减，突发流量来临时大量重建连接，拖慢响应 -
max_idle_time设太高（如默认60.0）：闲置连接长期不释放，占用数据库侧资源，尤其在 RDS 连接数有限时容易触发Too many connections -
connect_timeout推荐从默认10.0降到5.0：避免因网络抖动或 DNS 解析慢，让协程长时间卡在建连阶段，挤占连接池 - 所有连接池（Redis/MySQL/HTTP）的
wait_timeout建议统一设为相近值（如都用3.0），否则某类资源先耗尽会把压力转嫁给其他池，干扰问题定位
最易被忽略的是：连接池健康状态无法靠日志自动感知。你得主动用 hyperf:monitor 或自定义命令定期 dump PoolFactory::getPool('default')->getStats()，看 used 是否持续 > max_connections × 0.8 —— 这比等报错再查快得多。
