hyperf连接池验证需确保配置生效、观测实际连接数、排除干扰：清空runtime/container、检查databases.php中pool结构、确认swow启用；用show processlist等命令观测min/max连接数；压测验证wait_timeout与连接回收。
在测试环境验证 Hyperf 连接池连接数配置，核心是“让配置真实生效 + 观察实际行为 + 排除干扰”。不能只看配置文件写了多少，而要看运行时真正建立了几个连接、是否及时回收、是否触发排队或超时。
一、确认配置已加载且无冲突
Hyperf 的连接池配置极易因残留缓存或旧结构失效。必须做三件事：
- 删掉 runtime/container 目录（强制重建 DI 容器，否则旧 Pool 实例仍驻留）
- 检查 config/autoload/databases.php 中 MySQL/PostgreSQL/Redis 配置块内，
pool是独立子数组，且没有遗留的min_connections等顶层参数（Swow 下这些会被忽略） - 启动服务后，用
php bin/hyperf.php server:watch查控制台日志，确认输出含Swow\Coroutine\Channel或SWOW_BASE字样（说明 Swow 引擎已启用）
二、用命令行工具直接观测连接数
不依赖应用逻辑，用最轻量方式验证池是否按预期伸缩：
- 对 MySQL：启动后立即执行
mysql -u root -p -e "SHOW PROCESSLIST;" | wc -l，初始应接近min_connections值（如设为 8，看到 8–10 个 sleep 连接属正常） - 对 PostgreSQL：连入后执行
SELECT count(*) FROM pg_stat_activity WHERE state = 'idle';，数值应与min_connections基本一致 - 压测前先空跑一次：用
ab -n 10 -c 5 http://localhost:9501/api/test（简单接口），再查连接数，确认能短暂升至min_connections + 并发数范围内
三、模拟高并发并观察关键指标
用脚本制造可控压力，验证 max_connections 和 wait_timeout 是否起作用：
- 写一个循环请求接口的 PHP 脚本（不用协程，避免干扰），并发 20 次，每次请求后 sleep 0.1 秒，持续 30 秒
- 过程中实时监控：
watch -n 1 'mysql -u root -p -e "SHOW STATUS LIKE \"Threads_connected\";"' - 若连接数稳定在 64（你设的
max_connections），且无"No available connection"报错，说明上限生效；若出现大量wait timeout日志，说明wait_timeout过小或池不够用
四、检查连接是否真正归还
连接泄露是测试中最易被忽略的问题。验证方法很直接：
- 发起一批请求（比如 50 次），等全部返回后，等待 60 秒（超过
max_idle_time） - 再查
SHOW PROCESSLIST或pg_stat_activity，连接数应回落到min_connections附近 - 如果连接数居高不下（如始终卡在 40+），大概率是代码中用了
Db::connection()->getPdo()后没走框架生命周期管理，或事务未正确 commit/rollback
