Hyperf 3.1 启用 Swow 后原 pool 配置失效，根本原因是 Swow 完全不解析传统一级 pool 结构，仅识别 driver 同级的专用嵌套 pool；且必须删除旧配置、清空 runtime/container 缓存，并将 server.php 的 mode 改为 SWOW_BASE。
Hyperf 3.1 启用 Swow 引擎后，原有的 pool 配置失效，根本原因在于 Swow 的连接池管理机制与 Swoole 不兼容，且会主动忽略旧版配置结构。不是参数写错，而是框架底层根本不读取你原来写的 pool。
Swow 要求全新连接池结构，旧配置被静默跳过
Hyperf 在 Swow 模式下不再解析 config/autoload/databases.php 中传统的一级 pool 数组（比如直接写 'pool' => ['min_connections' => 4]）。它只识别 Swow 专用的嵌套结构——必须把 pool 配置放在 'driver' => 'mysql' 同级，并确保没有残留旧配置。
- ✅ 正确位置：
'mysql' => [ 'driver' => 'mysql', 'host' => env('DB_HOST', 'localhost'), // ... 其他数据库参数 'pool' => [ // ← 必须和 driver 平级，且不能有其他 pool 块 'min_connections' => 8, 'max_connections' => 64, 'check_interval' => 3000, 'heartbeat' => true, ], ], - ❌ 失效情况：
-
pool写在了最外层或嵌套层级错误； - 同时保留了旧版
pool配置（例如 Swoole 兼容模式下的全局 pool）； - 没删干净
databases.php里原生的pool项，Swow 会直接沿用兼容层，导致连接泄漏。
-
Swow 对关键参数有硬性校验，不满足就退化或报错
Swow 不是“兼容运行”，而是强制执行新规则：
-
check_interval必须 ≥ 3000（毫秒），否则心跳线程启动失败，空闲连接永不回收； -
retry_interval不能为 0，否则连接失败后彻底放弃重试； -
heartbeat单独设为true没用，必须配合max_idle_time和 MySQL 的wait_timeout才生效——否则只是假开启。
容器缓存残留导致新配置不加载
Hyperf 启动时会生成 runtime/container 下的 Pool 类实例。如果没清缓存就改配置：
- 旧
ConnectionPool类仍被复用； - 新
pool参数完全不参与初始化； - 表现就是连接数始终卡在旧值、
Too many connections反复出现。
解决方法只有一步到位：
rm -rf runtime/container php bin/hyperf.php start
没启用 Swow 模式，却以为启用了
常见误判：控制台没看到 Swow\Coroutine\Channel 字样，或 server.php 里仍是 'mode' => SWOOLE_BASE。Swow 必须显式启用：
-
config/autoload/server.php中mode改为SWOW_BASE； - 确保
php --ri swow输出正常，且SWOW_BASE常量已定义； - 启动时用
php bin/hyperf.php start（不是server:watch，热更新会干扰 Swow 初始化）。
不清理、不校验、不删旧配置，三者任缺其一，pool 就必然失效。
