Hyperf各版本连接数管理差异显著：v2.x依赖Swoole PoolManager直接读取；v3.x统一PoolInterface并集成Metric上报；v4.x适配Swow，暴露idle/available状态且需配置健康检查。
Hyperf 不同版本对连接数的获取和管理逻辑存在明显差异，核心区别在于连接池抽象层、协程引擎适配、以及配置结构的变化。不能简单复用旧版方式去查新版连接状态，否则可能拿到错误值或直接报错。
v2.x：基于 Swoole 的 PoolManager 直接读取
v2.x 时期连接池由 Hyperf\Pool\PoolManager 统一管理，每个数据库/Redis 实例对应一个独立 Pool 对象。连接数可通过 Pool 实例的公开方法实时获取：
$pool = $container->get(PoolManager::class)->get('default');-
$pool->getTotalConnections();—— 当前已创建总连接数 -
$pool->getAvailableConnections();—— 当前空闲可用连接数 -
$pool->getBusyConnections();—— 当前被占用连接数（需手动计算：total - available）
注意：该方式依赖 Swoole 4.x 的协程上下文，不适用于 Swow 或 Swoole 5.x 环境；且 v2.x 中无内置指标上报机制，需自行埋点。
v3.x：统一 Pool 接口 + Metric 集成支持
v3.x 开始抽象出 Hyperf\Pool\Contract\PoolInterface，所有连接池（MySQL、Redis、HTTP Client）均实现同一套接口。连接数获取更规范，同时原生支持 hyperf/metric 上报：
- 仍可通过
PoolManager::get($name)获取实例，调用getTotalConnections()等方法 - 推荐使用
Hyperf\Metric\Contract\MetricFactoryInterface获取连接池指标：$metric->gauge('db_pool_connections_total', $pool->getTotalConnections(), ['pool' => 'default']); - 框架默认开启
hyperf_db_pool_connections_total等指标（需启用hyperf/metric和 Prometheus 采集器）
与 v2.x 相比，v3.x 的 Pool 实现更轻量，getBusyConnections() 已为可选方法，部分自定义 Pool 可能未实现，应优先依赖 getTotalConnections() 与 getAvailableConnections() 计算。
v4.x：Swow 优先 + 连接生命周期显式暴露
v4.x 默认面向 Swow 协程引擎，连接池底层改用 Swow\Pool 封装，连接数统计逻辑下沉至 Swow 内核。原生 PoolManager 方法依然可用，但语义更严格：
-
$pool->getTotalConnections()返回的是 Swow Pool 中当前注册的连接总数（含正在销毁中的连接） -
$pool->getAvailableConnections()表示真正可立即分配的连接，Swow 会主动剔除心跳失败或超时 idle 的连接 - 新增
$pool->getIdleConnections()方法，明确区分「空闲但健康」与「空闲待清理」状态 - Swow 模式下必须设置
'check_interval' => 3000（≥3 秒），否则连接健康检查失效，getAvailableConnections()值将失真
若项目启用了 Swow，却仍用 v2/v3 方式查连接数，可能因底层连接回收策略不同而误判“连接泄漏”——实际是 Swow 提前释放了 idle 连接。
跨版本统一监控建议
避免硬编码调用不同版本的 Pool 方法。生产环境推荐以下方式：
- 统一走
hyperf/metric上报指标，通过 Prometheus 查询hyperf_db_pool_connections_total{pool="xxx"} - 在
AfterStart事件中注入自定义健康检查命令，封装兼容各版本的连接数读取逻辑 - 对 Swow 环境额外采集
swow_pool_idle_connections和swow_pool_busy_connections（需启用swow/metric扩展）
不复杂但容易忽略：连接数本身只是表象，关键要结合 wait_timeout 超时率、排队等待时间、MySQL 的 threads_connected 等外部指标交叉验证。
