swoole4高并发依赖连接池管理与资源复用，必须在onworkerstart中为每个worker预创建16～32个长连接，使用channel安全调度，获取时超时控制、归还前健康检查，并主动清理空闲超时连接。
连接池管理与资源复用是 Swoole4 高并发性能的底层支柱，不是锦上添花的功能，而是避免服务在流量高峰时直接崩塌的关键防线。核心在于：让每个 Worker 进程独立持有一组可循环使用的长连接，协程按需取用、用完即还，全程不新建、不关闭、不泄漏。
连接池必须在 onWorkerStart 中初始化
每个 Worker 进程拥有自己的内存空间和连接池实例，不能跨进程共享，也不能在请求回调（如 onReceive/onMessage）里重复创建。否则会快速耗尽数据库连接数或触发端口耗尽。
- 在 onWorkerStart 回调中一次性预创建连接，例如 16～32 个 MySQL 或 Redis 连接
- 使用 Swoole\Coroutine\Channel 替代 SplQueue 管理空闲连接，更安全、支持超时阻塞、天然协程友好
- 连接对象（如 Swoole\Coroutine\MySQL）创建后立即 connect()，失败则跳过并记录日志，不放入池中
获取与归还必须成对、及时、带校验
连接不是“借出去就不管了”，每次 use 后必须显式归还；归还前建议做基础健康检查，防止脏连接污染整个池。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 获取连接时，channel->pop($timeout) 带超时（推荐 0.5～1 秒），避免协程无限等待
- 执行 SQL 或命令后，调用 channel->push($conn) 归还 —— 不是 $conn->close()
- 归还前建议执行 $conn->connected && $conn->ping()，若失败则丢弃该连接，不入池
- 对 MySQL，特别关注错误码 2006（server has gone away）和 2013（lost connection），遇到即重建
连接生命周期要主动管控
长时间运行的服务中，空闲连接可能被中间设备（防火墙、LB）静默断开，或数据库主动踢出。靠被动报错再处理，体验差、风险高。
- 给每个连接打时间戳（如 last_used_time），归还时更新；获取时判断是否空闲超 5 分钟，超时则重建
- 配合定时器（如每 30 秒一次）扫描池中连接，主动 ping 并清理失效连接
- 设置合理的 connect_timeout（建议 3～5 秒）和 query_timeout（建议 1～3 秒），防止单个慢查询拖垮整池
连接数配置需贴合真实负载
池大小不是越大越好。过小导致排队等待，增大响应延迟；过大则浪费内存、压垮数据库。
- MySQL 连接池建议初始值设为 worker_num × 2～4，上限不超过数据库 max_connections 的 70%
- Redis 连接池可稍宽松（因 Redis 单连接吞吐高），但也不宜超过 64
- 观察实际运行时 channel->length() 和 channel->stats()，动态调整：length 持续接近容量 → 扩容；stats[‘consumer’] 明显高于 stats[‘producer’] → 可能瓶颈不在连接池
