ThinkPHP连接失败自动重试需显式开启break_reconnect且仅对PDO异常有效，依赖PDO::ATTR_ERRMODE设为EXCEPTION，Swoole等长连接环境需手动探活，事务中重试须重新开启事务。
连接失败时自动重试不生效？检查 think\db\Connection 的 break_reconnect 配置
ThinkPHP 默认不会在查询失败后自动重连，所谓“重试”必须显式开启且依赖底层驱动支持。核心开关是数据库配置里的 break_reconnect，它控制「查询报错后是否尝试重建连接」，但仅对 PDO 异常有效（如 MySQL 连接断开、超时），对语法错误或逻辑异常无效。
常见错误现象：SQLSTATE[HY000] [2006] MySQL server has gone away 报错后直接抛出异常，没重试；或者设置了 'break_reconnect' => true 却仍失败——大概率是 PDO 的 PDO::ATTR_ERRMODE 没设为 PDO::ERRMODE_EXCEPTION，导致异常被静默吞掉。
-
break_reconnect必须配合'debug' => true或日志捕获才能观察重试行为（否则重连成功也不输出） - MySQL 驱动下，重连只在连接层失效时触发，事务中执行失败不会重连（会直接 rollback）
- 若用连接池或 Swoole 长连接，
break_reconnect可能被绕过，需额外监听onClose事件手动重建
手动重试逻辑怎么写？用 try/catch 包裹 Db::transaction 或 query
框架不提供通用重试封装，业务关键操作必须自己控制重试次数和间隔。重点不是“多试几次”，而是区分错误类型：网络抖动可重试，主键冲突或数据校验失败重试毫无意义。
使用场景：支付回调更新订单状态、秒杀扣减库存等强一致性要求但偶发网络不稳的环节。
立即学习“PHP免费学习笔记（深入）”；
- 捕获具体异常类，优先判断
think\db\exception\DataNotFoundException和think\db\exception\PDOException，其余异常直接抛出 - 重试前加
usleep(100000)（100ms），避免雪崩；最多 2～3 次，再失败就该告警而非硬扛 - 事务内重试必须重新开启事务，不能复用已 rollback 的上下文，否则报
There is no active transaction
示例：
for ($i = 0; $i < 3; $i++) {
try {
Db::transaction(function () {
Db::table('order')->where('id', 123)->update(['status' => 'paid']);
});
break;
} catch (\think\db\exception\PDOException $e) {
if ($i === 2) throw $e;
usleep(100000);
}
}
配置文件里哪些参数影响重连行为？重点关注 deploy、host 和 params
ThinkPHP 的数据库配置不是扁平 key-value，deploy 模式（读写分离/集群）下重连逻辑会跳变，容易误以为“配置了却没用”。比如 deploy => 1 时，主库失败会切到从库，但不会重连原主库；而 deploy => 0 才走标准重连流程。
性能影响：每次重连都新建 PDO 实例，频繁触发会放大连接开销，尤其在高并发短连接场景下可能压垮 MySQL 的 max_connections。
-
host值不能写成127.0.0.1:3306，端口必须单独配port，否则 PDO 构造失败不抛异常，重连逻辑直接跳过 -
params数组里必须含PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，否则break_reconnect形同虚设 - 若用 Unix socket 连接（
unix_socket配置），重连时路径权限变化会导致失败，比 TCP 更难排查
为什么本地测试总成功，线上一断就崩？Swoole 环境下连接生命周期完全不同
Swoole Worker 进程常驻，PDO 连接对象不会随请求结束销毁，break_reconnect 在长连接模式下基本失效——因为连接没真正“断”，只是 MySQL 主动踢了闲置连接（wait_timeout 触发），而 PHP 层的 PDO 实例还活着，直到下次 query 才报错。
容易踩的坑：开发者按 FPM 思维配置，没意识到 Swoole 需要主动检测连接有效性。此时重试不是“连不上再试”，而是“连着但不可用，得先 ping 再操作”。
- 必须在每次查询前调用
Db::getPdo()->getAttribute(PDO::ATTR_CONNECTION_STATUS)或执行SELECT 1探活 - 不能依赖
onConnect回调做初始化重连，它只在 Worker 启动时触发一次 - 若用
think-swoole扩展，需监听WorkerStart事件并设置onWorkerStart中的连接池预热逻辑
复杂点在于：没有银弹方案。FPM 下靠配置，Swoole 下靠代码探活，协程环境下还得考虑 Co::sleep 替代 usleep。连不上只是表象，真正要厘清的是「连接何时算失效」「谁负责清理失效连接」「重试时机由谁判定」——这些边界一旦模糊，加再多层重试也只是掩盖问题。
