ThinkPHP报“Connection timed out”错误通常源于框架连接池等待可用连接超时，而非PDO网络连接超时；需检查DNS解析、PDO超时设置、MySQL wait_timeout、长连接配置及事务/闭包中连接泄漏问题。

Connection timed out 错误到底来自哪里 ThinkPHP 报 SQLSTATE[HY000] [2002] Connection timed out，别急着改 mysql.connect_timeout。这个超时大概率不是 PHP 连 MySQL 的网络层超时，而是 ThinkPHP 自己的连接池或连接复用逻辑在「等一个可用连接」时卡住了。底层 PDO 可能早已连上，但框架在 Db::connect() 时反复尝试获取连接失败，最终抛出这个误导性错误。

• 检查 database.php 中 'deploy' => 0（单库）时，'host' 是否写成了域名而非 IP —— DNS 解析慢会直接拖垮首次连接
• 确认 'params' => [\PDO::ATTR_TIMEOUT => 2] 这类设置是否被覆盖，ThinkPHP 5.1+ 默认不透传 PDO::ATTR_TIMEOUT，它只控制 PDO 初始化阶段，不影响后续查询
• 查看 MySQL 的 wait_timeout 和 interactive_timeout 值（执行 SHOW VARIABLES LIKE '%timeout%'），若设为 60 秒，而你的 CLI 脚本或队列任务运行时间超过这个值，空闲连接就会被 MySQL 主动断开，下次复用时就报 timeout

长连接不是开个 persistent 就完事 ThinkPHP 默认用的是短连接：每次请求结束自动 $pdo->close()。想用长连接，不能只在配置里加 'persistent' => true，那只是让 PDO 复用底层 socket，但 ThinkPHP 的连接管理器（Connection 类）仍可能在请求结束时调用 close()，导致 persistent 失效。

• 在 database.php 中启用前，必须同时设置 'break_reconnect' => true，否则连接异常后不会自动重连，反而更容易卡死
• 'persistent' => true 仅对 CLI 或 FPM 模式下的「同一 worker 进程内」有效；Apache prefork 模式下基本无效，因为进程不复用
• 更稳妥的做法是关闭 'persistent'，改用连接池式管理：在应用启动时预建几个连接存进 think\Cache，用 Db::setConnection() 手动注入，避免频繁创建销毁

连接泄漏常藏在事务和闭包查询里 ThinkPHP 的事务嵌套、闭包查询（Db::transaction(function () { ... })）容易导致连接未归还。尤其当闭包里抛异常但没被捕获，或者用了 return 提前退出，连接对象可能滞留在内存中，不再进入连接池回收队列。

• 避免在事务闭包里调用 exit、die 或未捕获的 throw new Exception
• 使用 Db::startTrans() + try/catch 时，确保 Db::commit() 或 Db::rollback() 总被执行，哪怕加 finally
• 检查自定义模型中是否重写了 initialize() 并在其中调用了 Db::connect() 却没保存引用，造成重复连接

监控连接数比调参数更管用 光调 max_connections 或 wait_timeout 是治标。真正该盯的是当前活跃连接数与 ThinkPHP 连接池实际持有数的差值。

• 在关键接口加日志：Db::getConnectCount() 返回当前已创建但未释放的连接数，配合 MySQL 的 SHOW STATUS LIKE 'Threads_connected' 对比，若前者远小于后者，说明连接被框架“漏管”了
• 不要依赖 Db::close() 手动关闭 —— 它只关当前连接，不清理连接池缓存，反而可能引发下次获取时拿不到干净连接
• 生产环境建议在 AppServiceProvider 中注册 shutdown 函数，记录每次请求结束时的连接状态，抓取异常增长点

连接池的生命周期和 MySQL 的连接清理策略不同步，才是大多数超时问题的根因。盯住 Db::getConnectCount() 和 Threads_connected 的实时差值，比翻文档调参数快得多。