ThinkPHP如何做数据库连接超时重连_ThinkPHP断线自动恢复机制【方法】

ThinkPHP 使用 PDO 连接 MySQL 时，mysqlnd 不主动检测连接超时，导致出现“MySQL server has gone away”而非连接异常；需手动执行 SELECT 1 探测并重连，禁用持久连接，CLI/Swoole 场景须主动管理连接生命周期。

连接超时后 mysqlnd 不抛异常，thinkphp 仍认为连接有效

在ThinkPHP中用PDO连MySQL，你一定遇到过这个问题：明明连接早就断开了，框架却浑然不知，直到真正发起查询时，才冷不丁蹦出一个 MySQL server has gone away 的错误。这个错误看起来像是连接失败，但本质上，它是在告诉你“连接曾经有效，但现在没了”。

问题出在底层驱动，比如 mysqlnd。它不会主动去检测连接是否还活着，所以ThinkPHP拿到手的是一个“僵尸连接”，自然也不会触发任何重连逻辑。于是，框架直接把这个异常抛给了你，或者返回一个空结果，让你一脸懵。

• 错误现象很明确：SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
• 触发场景也不陌生：MySQL的 wait_timeout 或 interactive_timeout 到期（默认8小时），这在长任务、队列进程、CLI模式下尤其常见，因为它们会把连接空闲很久。
• 根本原因在于：thinkphp 的 Db::connect() 不会做心跳检测，->query() 之前也不会主动去 ping 一下连接，结果就是只能硬扛错误。
• 解决思路其实很简单：在执行关键查询前，必须手动确认连接是否还活着，别指望框架能自动恢复。

Db::connect() 配置里加 'break_reconnect' => true 没用

很多开发者看到框架提供了一个 'break_reconnect' => true 的配置项，以为这就是“自动重连”的开关。很遗憾，这个配置的效果并没有想象中那么美好。

它的设计初衷是：在“查询执行过程中”发生连接中断时，尝试重连一次再执行。注意，它不是“连接前自动重连”，而是“执行失败后补救”。更要命的是，对于PDO驱动来说，这个逻辑基本不生效。一旦遇到 server has gone away，第一次失败就已经是不可逆的，重试也于事无补。

• 参数搭配有陷阱：'break_reconnect' => true 和 'deploy' => 1（读写分离）组合使用时，重连时机的判断逻辑会更加复杂，很容易误判。
• 性能成本不可忽视：每次查询都可能因为一次失败重试而增加响应延迟，而且无法避免第一次失败所导致的业务异常。
• 真实效果令人失望：遇到 server has gone away 时，大概率还是直接抛异常，并不会像你期望的那样静默恢复。

说白了，这个配置项解决不了根本问题。

手动 ping + 重连的最小可行方案

最可靠的做法，就是在执行关键查询前，主动去探测一下连接的状态。PDO本身没有提供 ping() 方法，但我们可以用更直接的方式：Db::getPdo()->exec('SELECT 1')。这比调用 getAttribute(PDO::ATTR_CONNECTION_STATUS) 更准确，也更轻量。

当然，你不能在每个查询前都手动去写这段逻辑，那样太傻了。更好的做法是封装一下：在模型基类或者中间件中统一拦截，比如重写 BaseModel::getConnection()，加上一层连接保活的逻辑。

一个示例实现是这样的：

try {
    $pdo = Db::getPdo();
    $pdo->exec('SELECT 1');
} catch (\PDOException $e) {
    if (strpos($e->getMessage(), 'MySQL server has gone away') !== false) {
        Db::close(); // 强制关闭旧连接
        Db::connect(); // 触发新连接
    }
}

务必注意：不要在事务执行期间做这个探测，否则很可能破坏事务的一致性。

CLI 进程和长连接场景必须主动管理生命周期

Web请求是天然的短生命周期，连接用完就丢，问题不大。但CLI场景，比如队列消费者、定时任务等，它们会复用一个连接数小时，超时几乎是必然事件。

所以，下面这几件事必须做到位：

• 必须主动做：启动时记录下连接的创建时间，然后在每次查询前检查一下，当前时间是否已经超过了 wait_timeout - 30 秒。一旦接近超时阈值，就主动重建连接。
• 千万别指望自动恢复：__destruct 或 register_shutdown_function 这类回调，它们的执行时机没有保证，不能依赖它们来关闭或重建连接。
• 兼容性警告：PHP 8.1+ 引入了 PDO::ATTR_PERSISTENT（持久连接），这玩意儿会加剧问题。持久连接更难被回收，建议直接禁用。
• 一个容易被忽略的陷阱：在Swoole或Hyperf这类常驻内存框架里，Db 实例是单例的，连接状态会跨请求共享。如果不自己维护连接健康度，很容易因为一个请求的异常，影响到后续所有请求。

话说到这份上，该怎么做已经很清楚。核心就一句话：别指望框架自动处理，把连接的生命周期管理主动权拿在自己手里。