TP6 默认不自动重连，因initConnect(false)不检测连接存活；需在query/execute前用getAttribute(PDO::ATTR_SERVER_INFO)轻量探测并手动重连，连接池中还需确保获取后立即校验。
连接超时后 TP6 默认不自动重连
ThinkPHP 6 默认使用 PDO 连接 MySQL，但 PDO::ATTR_EMULATE_PREPARES 和 PDO::ATTR_ERRMODE 等配置不会触发自动重连；一旦连接因 wait_timeout 或网络抖动中断，后续查询直接抛出 PDOException: SQLSTATE[HY000] [2006] MySQL server has gone away，而不是重试。
这是因为 TP6 的 Connection 类在执行 query() 或 execute() 前，只调用 $this->initConnect(false) —— 第二个参数为 false 表示「不强制重连」，它只会检查连接是否已初始化，不验证是否还活着。
- 真实场景中，MySQL 默认
wait_timeout=28800（8 小时），但连接池空闲、NAT 超时、LB 断连都可能让连接提前失效 - TP6 的
keepalive配置（如'deploy' => 1+'rw_separate' => true）仅影响读写分离路由，不解决单连接存活检测 - 不要依赖
'break_reconnect' => true：它只在主从切换失败时兜底，不是连接异常重试开关
手动触发重连的可靠时机是 query/execute 前
最稳妥的方式是在每次执行 SQL 前主动探测连接有效性。TP6 提供了 $connection->getPDO()，但直接调用 PDO::getAttribute(PDO::ATTR_SERVER_VERSION) 开销大；更轻量的是发一个低成本 ping：
// 在自定义 BaseDao 或 Db::event('before_execute') 中插入
try {
$pdo = $connection->getPDO();
$pdo->getAttribute(PDO::ATTR_SERVER_INFO); // 不会触发查询，但会暴露连接断开
} catch (\PDOException $e) {
if (strpos($e->getMessage(), 'MySQL server has gone away') !== false) {
$connection->close(); // 清掉旧连接引用
$connection->initConnect(true); // 强制重建
}
}
- 避免用
SELECT 1：虽然直观，但在高并发下会额外增加一次 round-trip，且可能被慢日志误判 - 不要在构造函数或
__clone()里做探测：连接对象常被复用，初始化时未必需要活跃连接 - 若使用
Db::name('user')->find()这类链式调用，需通过事件钩子切入，推荐监听think\db\Connection::before_execute
连接池场景下重连逻辑要区分「新连接」和「复用连接」
当开启 'pool_size' => 10 后，TP6 使用 ConnectionPool 管理连接对象，但池内连接仍可能过期。此时不能只靠 initConnect(true)，因为：
立即学习“PHP免费学习笔记（深入）”；
- 池中某个
PDO实例已断开，initConnect(true)只会新建一个连接并替换当前实例，但池里其他断连连接仍存在 - 下次从池中取出该连接时，依然会报错 —— 池本身不校验连接健康状态
- TP6 没有内置的连接有效性校验回调（如 Go 的
TestOnBorrow），必须自己包装getConnection()
建议在获取连接后立即做轻量探测：
$connection = Db::getConnection();
try {
$connection->getPDO()->getAttribute(PDO::ATTR_SERVER_INFO);
} catch (\PDOException $e) {
$connection->close();
// 强制从池中重新取一个（会触发 new PDO）
$connection = Db::getConnection();
}
注意：该逻辑不能放在全局中间件，必须紧贴 DAO 层或模型操作前，否则可能干扰事务上下文。
生产环境必须配合 MySQL 配置与监控
纯靠 PHP 层重连只是补救，治标不治本。关键配置要对齐：
- PHP 端
options' => [PDO::ATTR_TIMEOUT => 3]控制 connect timeout，但不影响 already-established 连接的保活 - MySQL 端应调低
wait_timeout（如 300 秒），让连接更快释放，减少“假存活”；同时确保interactive_timeout与之相等 - 若用阿里云 RDS 或腾讯云 CDB，务必关闭「连接保持」类代理功能，它们常静默断连却不发 FIN，导致 PHP 层无法感知
- 上线前用
tcpdump -i any port 3306抓包确认：连接断开时是否真收到 RST 或 FIN，还是直接丢包
真正难处理的是 NAT 超时（如 K8s Service + NodePort 场景），这时即使 MySQL 和 PHP 都认为连接正常，中间设备已悄悄切断，只能靠应用层心跳或缩短 wait_timeout 来暴露问题。
