ThinkPHP需显式启用break_reconnect=true并使用pdo_mysql驱动才能在MySQL长连接断开后自动重连，但事务中失效且首次查询仍报错。
MySQL长连接断开后ThinkPHP直接报错，不重连
ThinkPHP默认不会自动重连已失效的MySQL连接，一旦连接因wait_timeout或网络抖动中断，后续查询会抛出类似PDOException: MySQL server has gone away的错误。这不是TP框架bug，而是PDO底层行为——它不主动探测连接状态，只在执行SQL时才发现断了。
解决核心是让TP在报错后触发重连，而不是抛异常终止请求。关键靠配置项break_reconnect，但它必须配合其他条件才生效：
-
break_reconnect必须设为true（默认是false） - 数据库驱动必须是
pdo_mysql（非mysqli或mysql） - 不能在事务中触发断连（事务内重连会被忽略，避免数据不一致）
- 重连仅对下一条查询生效，不是“后台悄悄恢复”，所以首次失败仍会报错，但第二次查询能继续
如何正确开启break_reconnect并验证是否生效
在config/database.php中修改数据库配置，重点是params和break_reconnect两项：
'mysql' => [
'type' => 'pdo_mysql',
'hostname' => '127.0.0.1',
'database' => 'test',
'username' => 'root',
'password' => '',
'hostport' => '3306',
'charset' => 'utf8mb4',
'prefix' => '',
'debug' => true,
'break_reconnect' => true, // 必须显式开启
'params' => [
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::ATTR_PERSISTENT => false, // 长连接要用true？别急，往下看
],
],
注意：PDO::ATTR_PERSISTENT => true虽然叫“持久连接”，但在TP中开启反而会让break_reconnect失效——因为PDO持久连接由PHP进程管理，TP无法控制其重连逻辑。所以生产环境建议保持false，靠break_reconnect做应用层兜底。
立即学习“PHP免费学习笔记（深入）”；
为什么开了break_reconnect还是没重连
常见失效场景有三个，按出现频率排序：
- 用了
mysqli驱动：检查type是否为pdo_mysql，mysqli不支持该参数 - 在事务里断连：
Db::startTrans()之后连接断开，TP不会重连，直接抛异常，这是设计使然，避免事务语义被破坏 - 连接池或中间件提前复用连接：某些部署环境（如Swoole常驻进程）下，连接可能被多个请求共享，而TP的
break_reconnect只作用于当前请求生命周期内的连接对象，跨请求无效
验证是否真生效：手动杀掉当前连接（KILL CONNECTION xxx），再执行一次查询，观察日志里是否出现reconnect success字样（需开启debug）或第二条查询成功返回。
长连接 + break_reconnect 的真实性能影响
这个组合不是“零成本”方案。每次重连意味着额外一次TCP握手+鉴权+初始化，耗时约5–50ms（取决于网络）。高频短请求下，如果断连频繁，反而比短连接更慢。
真正适合它的场景是：
- 低QPS、长周期任务（如后台导出、定时同步）
- 数据库侧
wait_timeout设得较大（如28800秒），连接自然断开概率低 - 网络稳定，断连主因是MySQL主动回收空闲连接，而非丢包或防火墙中断
如果你的应用跑在K8s里且Pod经常重建，或者用云数据库（如阿里云RDS）启用了连接池代理，那break_reconnect意义不大——连接中断更多来自代理层，TP根本收不到MySQL server has gone away，而是直接超时或拒绝连接。
