pdo::attr_persistent不是连接池，仅在php-fpm/apache下复用连接，无容量控制、空闲回收和健康检查；swoole协程池才具备完整连接池能力，需预建连接、pop/push严格归还、避免混用阻塞与非阻塞驱动。
PHP本身没有内置连接池，所谓“连接池”是开发者在应用层或运行时环境（如Swoole）中模拟出来的资源复用机制。它不是银弹，只在特定高并发、低延迟场景下真正起效；FPM模式下硬套连接池反而容易引发连接泄漏或超限崩溃。
为什么PDO::ATTR_PERSISTENT不是连接池
PDO::ATTR_PERSISTENT 只是让PHP-FPM worker进程在请求结束后不关闭连接，而是交给下一个同worker的请求复用。但它不具备连接数限制、空闲回收、健康检查等池化能力：
- 连接归属不可控：不同请求可能复用同一连接，导致事务/会话状态污染
- 无超时管理：失效连接长期滞留，
mysql has gone away错误频发 - 无法跨worker共享：每个FPM子进程维护独立连接，总连接数 =
pm.max_children × persistent_connections_per_worker，极易突破MySQL的max_connections
Swoole协程连接池才是真连接池
只有在Swoole协程环境下，才能实现带容量控制、自动归还、协程安全的连接池。关键点在于使用Swoole\Coroutine\Channel或SplQueue做连接容器，并配合go()协程调度：
- 初始化时预建固定数量连接，例如
new Swoole\Coroutine\Channel(20) - 获取连接必须用
$channel->pop()，归还必须用$channel->push($conn)，缺一不可 - 不能混用
PDO和Swoole\Coroutine\MySQL：前者阻塞，后者协程非阻塞，混用会导致协程调度卡死 - 连接创建失败时需重试或降级，否则
pop()会永久阻塞（除非设超时）
哪些场景真需要连接池？
别被“高并发”三个字带偏——要看数据库操作密度和响应敏感度：
- 微服务间高频RPC调用，单次请求含3+次DB查询，且P99要求
- 秒杀/抢购类接口，瞬时QPS > 300，且每请求必查库存+写订单
- 实时报表聚合任务，需轮询多个分表并汇总，连接建立开销占比 > 30%
- 反例：后台CMS管理页，每小时才几十次访问，加连接池纯属增加复杂度
最容易被忽略的两个坑
一是连接归还不及时：业务逻辑抛异常后没走release()，连接永远卡在使用中，池迅速枯竭；二是忘记设置wait_timeout与连接池idle_timeout对齐，MySQL主动断连后，池里还存着“僵尸句柄”，下次query()直接报MySQL server has gone away。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
