Swoole连接池必须显式管理连接生命周期，因Worker进程常驻内存，协程间共享连接需手动归还，否则连接泄漏导致池枯竭、fd耗尽或OOM；PHP-FPM则每次请求结束自动销毁连接，无法池化。
连接池不是“开了协程就能自动复用”，而是必须显式管理连接生命周期——不手动归还，连接就永远卡在协程里，池子会迅速枯竭。
为什么 Swoole 连接池不能靠 PHP-FPM 那套思路？
PHP-FPM 每次请求结束就销毁全部变量，$redis 或 $mysql 实例一走就没了，根本没法“池化”。Swoole 的 Worker 进程常驻内存，才具备连接复用的前提。但这也带来新问题：协程之间共享同一进程空间，却不能共享连接对象——一个连接被协程 A 取出后，若没归还，协程 B 就永远等不到它。
- 常见错误现象：
count($pool) === 0频繁触发，导致每次请求都新建连接，最终Too many open files - 关键区别：FPM 下“连接即用即弃”是常态；Swoole 下“用完不还”等于泄漏
- 性能影响：未归还的连接持续占用 fd 和内存，Worker 进程内存缓慢上涨，数小时后 OOM
Swoole\ConnectionPool 和手写 SplQueue + Channel 的本质差异
Swoole\ConnectionPool（v4.5+）是官方封装的通用池基类，它只管“取”和“还”的调度逻辑，不关心连接类型；而手写方案（比如用 SplQueue 或 Swoole\Coroutine\Channel）需要自己处理连接创建、健康检查、超时回收等细节。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 使用场景：
Swoole\ConnectionPool适合 MySQL/Redis 等标准客户端；TCP 自定义协议建议手写Channel方案，控制力更强 - 参数差异：
Swoole\ConnectionPool构造函数第一个参数是工厂闭包，第二个是最大容量（如10），不提供空闲连接自动销毁接口 - 兼容性注意：低于 v4.5 的 Swoole 必须手写，且
SplQueue非线程安全，高并发下需配合co::sleep(0)或锁机制
连接归还时机错位：最常见的“假死”原因
很多人把 $pool->put($conn) 放在 try-catch 的 finally 块里，看起来很稳妥——但协程里一旦发生未捕获异常（比如 JSON 解析失败、下游 HTTP 返回非 200），finally 不一定执行。更隐蔽的是：协程被强制取消（如超时 go() 被 kill）时，finally 完全不会触发。
- 正确做法：所有业务逻辑结束后，**显式调用归还方法**，且不依赖异常流程
- 推荐结构：
go(function () use ($pool) { $conn = $pool->get(); // ... 业务操作 $result = $conn->query('SELECT ...'); $pool->put($conn); // 必须在这里，不要塞进 finally }); - 容易踩的坑：用
defer模拟 Go 风格延迟执行，在 Swoole 协程中不可靠，不生效
空闲连接不释放，比连接不够更危险
连接池长期持有 10 个连接，但实际 QPS 很低，这 10 个连接可能在 Redis/MySQL 侧被服务端主动断开（如 wait_timeout=60），而池子不知道，下次取出就报 Connection closed 或静默失败。
- 必须做健康检查：取出连接前 ping 一下（
$redis->ping()），失败则丢弃并新建 - 空闲超时不能只靠服务端：应在池子内部维护每个连接的最后使用时间戳，超过阈值（如 30 秒）就 close 并从队列移除
- 监控盲区：没有记录“归还失败次数”或“新建连接频率”，就无法判断是业务逻辑漏还，还是连接本身不稳定
连接池的复杂点不在创建，而在“谁在什么时候以什么方式把它还回来”——这个动作必须原子、确定、可观测。任何依赖语言运行时自动清理的假设，在 Swoole 协程长生命周期里都会失效。
