CI/CD中检查Hyperf连接池的核心是配置合规性校验与启动健康探查：校验databases.php/redis.php中min/max_connections存在且合理、禁用旧式pool配置、Redis wait_timeout在2.0–5.0间，并通过最小化实例初始化连接池验证配置可加载。
在 CI/CD 流程中检查 Hyperf 连接池连接数，核心目标不是“运行时监控”，而是“配置合规性校验 + 启动健康探查”。因为 CI/CD 环境通常无真实数据库/Redis 服务，也不能依赖长期运行的指标采集，所以重点放在静态配置扫描和轻量级启动验证上。
检查 config/autoload 中的连接池参数是否合理
这是最可靠、最易集成进 CI 的一步。可编写 Shell 或 PHP 脚本，在构建阶段读取 config/autoload/databases.php 和 config/autoload/redis.php，校验关键字段是否存在且落在安全范围内：
-
必须存在
min_connections和max_connections：缺失即报错，避免使用默认值（如 MySQL 默认 max_connections=10）导致线上连接耗尽 -
max_connections不得超过数据库侧限制：例如 MySQL 默认为 151，CI 脚本可硬编码检查<= 100；若项目已配DB_MAX_CONNECTIONS环境变量，应确保配置值 ≤ 该变量 -
Swow 环境下禁止出现旧式 pool 配置：检查是否残留
'pool' => ['minimum' => ...]这类 Swoole 风格写法，存在则提示“需迁移到 Swow 专用结构” -
Redis 的
wait_timeout应在 2.0–5.0 区间，低于 1.0 易误超时，高于 8.0 会掩盖真实瓶颈
启动最小化服务并触发连接池初始化
在 CI 中启动一个极简 Hyperf 实例（不加载 Controller、不监听 HTTP），仅初始化 DI 容器和连接池工厂，验证配置能成功加载且不崩溃：
- 新建
bin/check-pool.php，内容为：
require_once __DIR__ . '/../vendor/autoload.php';
$container = require __DIR__ . '/../config/container.php';
try {
// 触发数据库连接池初始化
$container->get(\Hyperf\Pool\PoolFactory::class)->getPool('default');
// 触发 Redis 连接池初始化（如有）
if ($container->has(\Hyperf\Redis\Pool\PoolFactory::class)) {
$container->get(\Hyperf\Redis\Pool\PoolFactory::class)->getPool('default');
}
echo "✅ 连接池配置加载成功\n";
} catch (\Throwable $e) {
echo "❌ 连接池初始化失败: " . $e->getMessage() . "\n";
exit(1);
}
- 在 CI 步骤中执行：
php bin/check-pool.php，非零退出即失败 - 该方式不连真实后端，只做配置解析与对象构建，快且稳定
结合容器化环境做端口连接模拟（可选增强）
若 CI 使用 Docker 并允许启动临时服务（如 Testcontainers），可进一步验证连接池行为：
- 用
mysql:8.0和redis:7-alpine启动两个容器，配置固定max_connections=50和maxclients=100 - 修改
.env指向这两个容器，再运行上面的check-pool.php - 追加一行：调用
$pool->getCurrentConnections()并断言 ≥min_connections，确认预热连接确实建立
禁止在 CI 中依赖运行时指标采集
像 Prometheus 抓取 hyperf_db_pool_connections_total 或调用 mysqld_exporter 这类做法不适合 CI：
- 指标暴露需完整服务启动 + HTTP server + metrics 中间件，启动慢、依赖多
- 连接数是动态值，单次采样无意义；而 CI 需要的是确定性判断
- 容易因网络抖动、端口冲突等非配置问题导致误报
