ThinkPHP连接池不支持连接泄露检测，仅通过pool.timeout（占用超时）和break_reconnect实现兜底清理，需结合MySQL的SHOW PROCESSLIST与应用层日志人工排查泄露点。
ThinkPHP 连接池本身不支持连接泄露检测
ThinkPHP 的数据库连接池（基于 think\db\Connection 和底层 PDO）是「懒连接 + 复用 + 自动释放」机制，它没有内置的连接泄露扫描器、存活心跳探针或超时强制回收逻辑。所谓「连接泄露检测周期」在官方代码里根本不存在——你配置了也无效。
常见错误现象：max_connections 被耗尽、MySQL 报错 Too many connections、show processlist 里大量 Sleep 状态长连接；但日志里找不到明确泄露点。
- ThinkPHP 不会主动扫描「哪些连接该关却没关」
- 连接是否泄露，取决于你的代码是否显式调用了
close()，或是否在协程/长生命周期脚本中意外持有了Connection实例 - 配置项如
pool.size、pool.timeout控制的是连接复用池行为，不是泄露检测周期
真正能控制连接生命周期的是 pool.timeout 和 break_reconnect
这两个参数决定了连接在空闲多久后被主动丢弃，间接缓解「疑似泄露」问题——但它不是检测，而是兜底清理。
使用场景：高并发短请求（如 API）下，避免连接长期闲置占满池子；但对协程服务（如 Swoole）必须谨慎，因为连接可能跨请求复用。
立即学习“PHP免费学习笔记（深入）”；
-
pool.timeout：单位秒，连接从池中取出后，若超过该时间未归还，会被自动销毁（注意：不是「空闲超时」，是「占用超时」） -
break_reconnect：设为true时，当连接异常断开，会尝试重建而非直接抛错；但不会触发泄露检查 - 示例配置：
'mysql' => [ 'type' => 'mysql', 'hostname' => '127.0.0.1', 'database' => 'test', 'pool' => [ 'size' => 20, 'timeout'=> 60, // ⚠️ 这是「最长持有时间」，不是扫描间隔 ], ]
要查连接泄露，得靠 MySQL 侧 + 应用层日志交叉分析
ThinkPHP 没有埋点上报连接状态，所以必须自己加钩子或依赖外部工具。别指望改个配置就自动发现哪行代码忘了 $db->close()。
常见错误现象：Swoole Worker 内全局缓存了 Db::name('user') 查询对象、事务未 commit/rollback 就退出作用域、异常分支遗漏 finally { $conn->close() }。
- MySQL 侧执行
SHOW PROCESSLIST，重点关注Command=Sleep且Time值持续增长的连接，记下Id和Info - 在 ThinkPHP 配置中开启
debug模式，并设置log.sql为true，配合trace日志定位连接创建位置 - 关键点：连接泄露往往发生在「非标准请求生命周期」里，比如命令行任务、WebSocket 回调、定时器回调——这些地方
Db实例容易被闭包捕获而无法释放
协程环境下必须手动管理连接，否则必泄露
Swoole 协程 + ThinkPHP 8.0+ 的 Connection 默认不是协程安全的，且不会自动绑定协程上下文。一旦你在 go 块里复用同一个 Db 实例，连接就会被多个协程争抢，导致状态错乱和连接卡死。
性能影响：一个泄露的连接会持续占用 MySQL 线程，叠加后直接拖垮 DB 吞吐；兼容性上，pdo_mysql 扩展在协程下需启用 mysqlnd 并开启 coroutine 支持。
- 正确做法：每次协程内用
Db::connect()新建独立连接，或使用Db::connection('name', true)强制获取新实例 - 绝对避免：把
Db实例赋值给全局变量、静态属性、或跨go传递 - 验证方式：在协程函数末尾加
echo Db::getPdo()->getAttribute(PDO::ATTR_CONNECTION_STATUS);，应输出Connection OK；若报错或返回空，说明连接已失效或被其他协程污染
Db 实例的持有范围比你想的更危险。 
