thinkphp 6.x 连接池默认不启用空闲检测，idle_timeout 等配置仅在 swoole 协程池（如 swoole\coroutine\mysql）下生效；pdo 场景需手动心跳探活或重写 initconnect 方法。
ThinkPHP 连接池空闲检测默认不生效
ThinkPHP 6.x 的 ConnectionPool 类本身不内置空闲连接扫描逻辑，所谓“空闲检测间隔”其实是底层连接器（如 PDO）或中间件（如 Swoole 协程池）的行为，TP 框架层并未实现定时扫描、踢除超时空闲连接的机制。你看到的 idle_timeout 或 max_idle_time 配置项，只在使用 Swoole\Coroutine\MySQL 或 Hyperf\Pool 等协程池组件时才起作用；纯 TP + PDO 场景下，这些配置基本被忽略。
- 常见错误现象：
mysql server has gone away错误频发，尤其在长周期 CLI 任务或低频 HTTP 请求中 - 真实使用场景：Swoole Worker 持久化运行、队列消费者常驻进程、定时脚本复用连接
- TP 自带池管理只做“借还”不负责“巡检”，空闲连接是否失效，完全依赖数据库
wait_timeout和 TCP keepalive 设置
如何让 Swoole 协程环境下真正启用空闲检测
只有当你用 Swoole\Coroutine\MySQL 替换默认 PDO，并配合 think-swoole 或自定义协程池时，idle_check_interval 才有意义。它控制协程池内部定时扫描空闲连接的时间间隔（单位：秒），扫描后会关闭超过 max_idle_time 的连接。
- 必须显式配置池参数，TP 的
database.php中的pool配置需完整传递给协程池构造器 -
idle_check_interval最小建议设为30，太小会增加 CPU 轮询压力；太大则失效连接滞留时间过长 -
max_idle_time应略小于 MySQL 的wait_timeout（比如 MySQL 设为60，这里设50），否则检测时连接还没被 DB 主动断开，池不会主动清理 - 示例关键配置片段：
'pool' => [
'min_idle' => 1,
'max_idle' => 20,
'max_active' => 30,
'idle_check_interval' => 30,
'max_idle_time' => 50,
],
PDO 场景下模拟空闲检测的务实做法
如果你没上 Swoole，只是普通 FPM 或 CLI，又想避免 MySQL server has gone away，就得自己动手——TP 不提供，但可以低成本补上。
- 在每次
Db::connect()前，手动执行PDO::getAttribute(PDO::ATTR_CONNECTION_STATUS)并捕获异常，失败则重建连接 - 更稳妥的做法是重写
think\db\Connection的initConnect()方法，在建立连接后立即执行SELECT 1心跳探活 - 不要依赖
PDO::ATTR_TIMEOUT，它只控制连接建立超时，不控制空闲超时 - 注意：FPM 下每个请求都是新进程，连接天然不复用，此问题多出现在 CLI 常驻进程中；若你用的是
think-queue的worker:monitor，务必确保--daemon模式下连接有重连逻辑
容易被忽略的关键点
很多人调了 idle_check_interval 发现还是连不上，根本原因是没意识到：这个值只对协程池生效，而 TP 默认根本不走协程池。即使你装了 swoole 扩展，只要没在 config/database.php 里把 type 改成 swoole_mysql（或类似适配器），所有配置都只是摆设。
另外，max_idle_time 和 idle_check_interval 是两个独立参数：前者定义“一个连接空闲多久该被回收”，后者定义“每隔多久检查一次”。它们之间没有自动对齐逻辑，填错组合会导致连接池积压大量僵尸连接，或者过度频繁重建连接拖慢性能。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
