thinkphp连接泄漏需通过mysql侧监控活跃连接数变化来确认，重点关注sleep且time持续增长的连接；db::close()作用有限，事务和闭包中易漏连；测试阶段应自动化比对threads_connected前后值以检漏。
ThinkPHP 本身不提供连接泄漏的自动检测能力，必须靠外部手段+代码规范双管齐下才能发现泄漏点。光看日志或错误堆栈基本没用，真正泄漏时往往悄无声息，直到 MySQL 报 Too many connections。
怎么确认是不是连接泄漏了
别等线上崩了才查。最直接的办法是：在 MySQL 侧实时观察活跃连接数变化。
- 执行
SHOW PROCESSLIST;，重点关注Command列为Sleep且Time持续增长（比如 >300 秒）的连接，这些极大概率是未释放的 ThinkPHP 连接 - 对比应用启动后和高并发压测后的连接数：如果连接数随请求数线性上涨、不回落，基本可断定泄漏
- 注意区分「空闲连接」和「泄漏连接」：ThinkPHP 默认短连接，每个请求结束就该断开；若看到大量
Sleep连接长期挂着，就是泄漏信号
为什么 Db::close() 不一定管用
TP6.1+ 提供了 Db::close()，但它的作用范围很有限，容易误以为调用了就万事大吉。
-
Db::close()只关闭当前请求中「最后一次调用Db::connect()得到的那个连接实例」，对事务中创建的额外连接、模型内部隐式获取的连接无效 - 在 Swoole 协程环境里，
Db::close()可能根本不起作用 —— 因为底层用的是swoole_mysql或co\mysql，而think\db的 close 逻辑压根没走协程驱动 - TP5 没有公开的
Db::close()，得用反射调用Connection::destroy()，但这个方法只销毁对象，不保证底层 PDO 断开，尤其开了persistent => true时更不可靠
事务和闭包里最容易漏连接
ThinkPHP 的 Db::transaction() 和闭包查询是泄漏重灾区，因为异常路径下连接归还不确定。
- 闭包里抛出未捕获异常（比如
throw new Exception()），Db::transaction()的 finally 块可能没执行，连接就卡在内存里 - 用了
return提前退出闭包，同样会跳过 commit/rollback，连接不会被回收 - 自定义模型的
initialize()方法里手动调了Db::connect()却没存到属性上，导致连接对象变成临时变量，GC 不会主动清理它 - 解决方案不是加 try/catch 就完事，而是统一用
Db::startTrans() + finally { Db::commit() / Db::rollback() }显式控制，避免依赖闭包自动回收
测试阶段怎么自动化检漏
单元测试跑完后检查连接数是否复位，是最靠谱的预防手段。不能只靠人工肉眼盯。
- 在测试类的
@Before阶段记录 MySQL 当前Threads_connected值（查SHOW STATUS LIKE 'Threads_connected'） - 在
@After阶段再查一次，差值 > 0 就说明这个测试用例泄漏了连接 - 注意排除干扰：确保测试运行期间没有其他进程连 MySQL；TP 配置里关掉
persistent，否则连接复用会让数值波动 - CI 流水线里把这个检查做成硬性门禁，一旦泄漏就 fail，比等线上报警快得多
连接泄漏最难缠的地方在于：它不报错、不中断业务，只默默吃光数据库连接数。你得在代码写完、测试跑通之后，再专门补一道「连接数前后对比」的验证，而不是指望框架替你兜底。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
