Hyperf 3.1在Swoole与Swow下连接池配置逻辑完全不同：①Swoole用扁平pool数组，Swow必须删除旧配置、新增结构化'pool'=>[]；②Swow要求check_interval≥3000ms、retry_interval≠0、heartbeat显式设true；③Swow依赖swow.so≥1.5.0及hyperf/db Swow适配分支，启动需见Swow\Coroutine\Channel日志。
Hyperf 3.1 在 Swoole 和 Swow 两种协程引擎下，数据库连接池配置逻辑完全不同——不是简单改几个参数，而是结构、行为、校验规则都变了。用错配置轻则连接泄漏、idle 不回收，重则报 pool exhausted 或服务启动失败。
连接池配置结构必须重构
Swoole 模式下，config/autoload/databases.php 中的 pool 是扁平一级数组，支持 min_connections、max_connections 等字段直接写在 driver 同级；Swow 模式下，这套结构被完全弃用。
- Swow 要求删除所有旧
pool配置项，否则框架会降级走 Swoole 兼容层，导致连接不释放 - 必须在
'driver' => 'mysql'同级新增独立的'pool' => [...]数组，且该数组只被 Swow 引擎识别 - Swow 的 pool 是强结构化配置，字段缺失或类型错误（如
check_interval写成整数但单位错）会导致启动时静默忽略或心跳异常中断
关键参数含义与约束差异明显
表面相似的参数，在两个引擎中实际作用机制不同：
-
check_interval：Swoole 下无强制下限，常见设为 1000（毫秒）；Swow 要求 ≥ 3000 毫秒，低于此值会触发心跳检测中断 -
retry_interval：Swoole 可设为 0 表示立即重试；Swow 明确禁止为 0，否则连接失败后永不重试 -
wait_timeout：Swoole 默认单位是秒；Swow 统一为秒，但 Swow 对超时精度更敏感，建议显式写2.0而非2 -
heartbeat：Swoole 下默认开启；Swow 必须显式设为true才启用连接保活，否则 idle 连接可能被中间件或 DB 侧主动断开
依赖扩展和版本要求不可混用
数据库驱动底层依赖不同，直接影响配置是否生效：
- Swoole 模式依赖
swoole_mysql协程驱动，无需额外安装pdo_mysql.so（除非降级使用同步 PDO） - Swow 模式不兼容
swoole_mysql，必须确保hyperf/db使用的是 Swow 适配分支，且hyperf/redis≥ 3.2.5 才支持SwowHandler - Swow 要求 PHP 扩展
swow.so≥ 1.5.0，并在启动时确认控制台输出含Swow\Coroutine\Channel字样，否则仍走 Swoole 兼容路径
启动验证方式完全不同
不能只看服务是否起来，要确认连接池真实按预期工作：
- Swoole 模式可通过
netstat -an | grep :3306 | wc -l观察活跃连接数是否在min～max区间浮动 - Swow 模式需结合日志：开启
Hyperf\Database\Pool\ConnectionPool的 debug 日志，观察acquire/release是否成对出现，且idle数量稳定不持续增长 - Swow 下若出现大量
connection refused或timeout，优先检查SWOW_BASE是否已设、ulimit -n是否足够、以及max_connections是否超过 MySQL 的max_connections或系统ulimit限制
