Guzzle 7 高并发“连接池耗尽”本质是 cURL 多句柄或系统资源（文件描述符、TCP 连接、DNS 缓存）达上限；需协同优化客户端配置（复用 Client、限流、精调超时与 DNS）、系统参数（ulimit、TCP 调优）及架构（Swoole 协程、异步工作进程、Nginx 缓存）。
PHP 7.4 使用 Guzzle 7 高并发请求时出现“连接池耗尽”，本质是底层 cURL 多句柄（CurlMultiHandler）或系统资源（文件描述符、TCP 连接、DNS 缓存）达到上限，并非 Guzzle 自身有“连接池”概念——它复用的是 cURL 的 multi handle 和底层 socket，但默认行为未主动限流与复用管控。优化需从客户端配置、系统层、Guzzle 使用模式三方面协同处理。
精调 Guzzle 客户端配置，控制资源占用
避免每次 new Client()，全局复用单例，并显式约束连接生命周期：
- 设置 有限且合理的超时：禁用
CURLOPT_TIMEOUT=0，强制'timeout' => 5.0、'connect_timeout' => 3.0，防止慢响应长期占住句柄 - 启用 TCP 连接复用：通过
'handler' => HandlerStack::create(new CurlMultiHandler(['handle_size' => 10]))显式限制 multi handle 持有的并发句柄数（如设为 10），避免无节制创建 - 关闭不必要的功能：禁用重定向（
'allow_redirects' => false）、禁用 cookie（'cookies' => false），减少中间状态开销 - 复用 DNS 缓存：在 Client 构造时传入
'curl' => [CURLOPT_DNS_CACHE_TIMEOUT => 600]，避免高频请求反复解析域名
用 Pool 精确控并发，替代裸 promise 链
直接调用 $client->getAsync() 并批量 wait() 容易失控；必须用 Pool 统一调度：
-
硬性限制并发数：
'concurrency' => 8（根据 VPS CPU 核心数 × 2 向下取整，如 4 核建议设 6–8） - 配合 失败熔断：在
'rejected'回调中记录错误并考虑临时降级（如返回缓存或空数据），避免因个别接口抖动拖垮整体 - 避免无限请求队列：迭代器生成请用
yield，且总数可控；若需分页拉取，应在 Pool 外做批次切分，每批 Pool 控制在 50–100 请求内
系统级加固：释放底层瓶颈
Guzzle 表现异常，常因 OS 层资源见顶：
立即学习“PHP免费学习笔记（深入）”；
- 检查并提升文件描述符限制：
ulimit -n至少设为 65535，修改/etc/security/limits.conf持久生效 - 调优 TCP 参数：增大本地端口范围（
net.ipv4.ip_local_port_range = 1024 65535）、缩短 TIME_WAIT 超时（net.ipv4.tcp_fin_timeout = 30） - 验证 DNS 性能：用
dig api.example.com @8.8.8.8 +short测试解析延迟；若 >100ms，考虑在应用侧引入reactphp/dns或本地 hosts 映射高频域名 - 监控连接状态：执行
ss -s | grep 'tcp'查看当前 TCP 连接总数，若 ESTABLISHED 接近ulimit -n值，即为根本瓶颈
进阶替代方案（当 Pool 仍不稳定时）
若业务对吞吐和稳定性要求极高，可跳出传统 FPM 模式：
- 接入 Swoole 协程 HTTP 客户端：基于原生协程，无 cURL 多句柄开销，单进程轻松支撑数千并发，且自带连接池管理
- 将外部请求下沉为 独立异步工作进程：用 Laravel Horizon 或 Supervisor 管理常驻 PHP worker，接收队列任务后用 Guzzle Pool 执行，主站只发消息不等结果
- 前置 反向代理缓存：对幂等 GET 接口（如配置、静态数据），在 Nginx 层配置
proxy_cache，命中率高时可削减 70%+ 后端请求
