ThinkPHP空闲检测依赖max_idle_time配置与break_reconnect组合，并非独立模块，实际靠查询前校验+失败重连实现；MySQL的wait_timeout才是服务端断连根源。
ThinkPHP 连接池空闲检测靠什么触发
ThinkPHP 本身不提供数据库连接池实现，所谓“连接池空闲检测”实际是 PDO 连接复用 + 框架连接管理器的超时回收逻辑。核心依赖两个配置：deploy（是否启用分布式/多服务器）、max_idle_time（连接最大空闲秒数），后者仅在 deploy=1 且使用 PDO::ATTR_PERSISTENT 时部分生效——但 ThinkPHP 默认不开启持久连接。
常见错误现象：SQLSTATE[HY000] [2006] MySQL server has gone away 频繁出现，或日志里大量 Connection lost，误以为是“连接池没检测空闲”，其实是连接被 MySQL 主动断开后，框架未及时感知并重建。
-
max_idle_time在 ThinkPHP 6.x 中仅对mysql和pgsql驱动有基础支持，且只在下次查询前检查上一次使用时间，不是后台定时轮询 - 真正起作用的是
break_reconnect配置：设为true后，查询失败会自动重连一次，避免直接抛异常 - MySQL 的
wait_timeout（默认 28800 秒）和interactive_timeout才是决定连接何时被服务端关闭的根源，必须与应用层配置对齐
如何让 ThinkPHP 主动清理失效连接
不能依赖“定期清理”，得靠查询前校验 + 失败兜底。ThinkPHP 提供了 think\db\Connection 类的 ping() 方法，但框架不会自动调用它——你得自己插在关键路径上。
使用场景：长周期 CLI 任务（如队列消费者）、WebSocket 后端、Swoole HTTP 服务中复用连接时。
立即学习“PHP免费学习笔记（深入）”；
- 在执行 SQL 前手动调用
$connection->ping()，返回false则说明连接已断，需重建；但注意这会增加一次往返开销 - 更稳妥的做法是捕获
think\db\exception\DataNotFoundException或底层PDOException，判断错误码是否为2006或2013，再调用$connection->close()+$connection->initConnect() - 不要在
__destruct或finally块里无条件close()，ThinkPHP 的连接对象是单例，关掉会影响后续请求
Swoole 环境下连接复用的致命陷阱
Swoole 的常驻内存特性会放大 ThinkPHP 连接管理的缺陷：一个 Worker 进程启动后，Connection 实例长期存在，但 MySQL 可能在几分钟后就断开连接，而框架毫无察觉。
参数差异：max_idle_time 在 Swoole 中完全失效，因为连接对象生命周期远超该值；deploy=1 也无法触发后台检测。
- 必须在每次请求入口（如
onRequest回调）或数据库操作前，显式调用Db::connect()->ping() - 如果用了连接池封装（比如自研或第三方包），确保池内连接创建后设置了
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，否则错误会被静默吞掉 - 避免在
onWorkerStart里提前初始化 Db 连接——此时 MySQL 还没准备好，容易卡死或连上旧连接
为什么 config/database.php 里的 timeout 不起作用
timeout 配置项控制的是 PDO 连接建立阶段的超时（即 mysql_connect 阶段），不是连接空闲超时。很多人把它和 max_idle_time 混淆，导致调了半天没效果。
性能影响：盲目调小 timeout（比如设成 1 秒）会导致网络抖动时大量连接失败；调大又掩盖真实问题。
-
timeout对应 PDO 构造时的PDO::ATTR_TIMEOUT，仅作用于new PDO()这一瞬间 - 空闲检测真正的开关是
max_idle_time+break_reconnect组合，且必须搭配 MySQL 服务端的wait_timeout调整 - 验证是否生效：修改 MySQL 的
wait_timeout=60，然后用 CLI 脚本 sleep(70) 后查库，看是否报错并自动恢复
复杂点在于，空闲检测从来不是“独立模块”，而是连接创建、使用、异常处理、重连策略四者咬合的结果。少一环，就漏连。
