thinkphp连接池空闲超时由pool配置的max_idle_time控制，非数据库驱动处理；需显式开启pool，且max_idle_time须小于mysql wait_timeout至少60秒，tp8.0+才完整支持。
ThinkPHP 连接池空闲超时靠 pool 配置，不是靠数据库驱动自己处理
ThinkPHP 本身不实现连接池，所谓“连接池”是 PDO + 连接复用机制 + 框架层缓存的组合效果。真正控制空闲连接释放的，是配置里的 pool 选项，不是 MySQL 的 wait_timeout 或 PHP 的 max_execution_time。
常见错误现象：SQLSTATE[HY000] [2006] MySQL server has gone away，尤其在低频服务或定时任务中高频复现——说明连接被 MySQL 主动断开，而 ThinkPHP 还拿着旧连接没检测、也没重连。
-
pool配置必须显式开启，否则每次请求都新建连接，根本谈不上“空闲超时”管理 - 关键参数只有两个：
max_idle_time（单位秒）控制连接空闲多久后被回收；max_use_time（单位秒）控制单个连接最大存活时长（防内存泄漏或状态残留） - ThinkPHP 8.0+ 才完整支持
max_idle_time，7.x 只有max_use_time，且默认为 0（不限制），容易积累僵尸连接 - 该配置只对使用
Db::connect()或容器自动注入的连接生效，手动 new PDO 不受控
怎么配 max_idle_time 才不踩坑
设太小会导致频繁重建连接，增加 handshake 开销；设太大又无法及时清理被 MySQL 断开的连接。合理值取决于你的 MySQL wait_timeout（默认 28800 秒 / 8 小时），但必须比它小至少 60 秒。
- 查 MySQL 当前设置：
SHOW VARIABLES LIKE 'wait_timeout'; - 在数据库配置里写死：
'pool' => ['max_idle_time' => 28700]（比 wait_timeout 小 100 秒） - 别用
0或负数：ThinkPHP 会跳过空闲检查，等于关掉该机制 - 如果应用部署在容器或 Serverless 环境，
max_idle_time建议压到 300–600 秒，避免冷启动后首请求失败
Db::close() 不会触发空闲回收，得靠框架自动调度
调用 Db::close() 只是把当前连接从本次请求上下文中解绑，并不会立刻销毁底层 PDO 实例——是否回收，取决于连接是否还在 pool 中、以及是否超时。
- 手动
Db::close()后，下次Db::table()仍可能复用原连接（只要没超max_idle_time） - 真正触发回收的是下一次连接获取时的检查逻辑，不是 close 动作本身
- 不要在循环里反复
Db::connect()->close()，这反而干扰 pool 的健康判断 - 若需强制释放所有连接（如 CLI 脚本结尾），可用
Db::getInstance()->getPool()->clear()（TP8）
为什么改了配置还是看到 “gone away”？检查这三个点
空闲超时只是其中一环，MySQL 主动断连还可能来自网络、中间件、或连接未正确归还 pool。
- 确认配置加载成功：
var_dump(config('database.connections.mysql.pool'));，看max_idle_time是否生效 - 检查有没有地方用了
new \PDO()或Db::raw()绕过连接池，这类连接不受pool控制 - 查看 MySQL 错误日志是否有
Aborted connection，结合net_read_timeout和interactive_timeout判断是否是网络层中断
连接池空闲超时不是银弹，它只管“该不该留”，不管“能不能用”。真要稳，得让连接在用之前做一次简单探活，比如执行 SELECT 1，但这得自己加钩子——框架默认不做。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
