break_reconnect => true 仅在pdo异常且非事务/cli场景下生效，需同时满足type为pdo_mysql、pdo::errmode_exception、非事务内执行三个条件，否则不触发重连。
设了 break_reconnect => true 却还是断连，不是配置没生效，而是它根本没被触发——这个选项只在「查询执行中连接突然失效」时起作用，且依赖多个硬性条件同时满足。常见原因就这几个：
驱动类型不对：type 不是 pdo_mysql
break_reconnect 仅对 pdo_mysql 驱动有效。如果配置里写的是 mysqli 或旧版 mysql，该参数完全被忽略。
- 检查 config/database.php 中数据库连接配置的
'type'值，必须为'pdo_mysql' - 不要依赖框架自动推断；显式写出，避免因 .env 覆盖或多环境配置错位导致 type 变更
PDO 错误模式没设对：缺少 PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
PDO 默认用静默模式（PDO::ERRMODE_SILENT），错误不抛异常，ThinkPHP 就收不到信号，自然跳过重连逻辑。
- 必须在
'params'数组中明确加上：PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION - 仅设
break_reconnect => true不够，这两项是绑定生效的“组合键”
连接发生在事务中或 CLI 常驻进程里
事务内连接中断，TP 会直接报错并 rollback，禁止重连——这是刻意设计，防止事务语义错乱。
- Db::startTrans() 后发生的断连，
break_reconnect不起作用 - CLI 模式（如队列 work 进程）是长生命周期，连接复用到底；而
break_reconnect只在单次查询失败后尝试一次重建，无法应对空闲期被 MySQL 主动踢掉的情况 - work 模式建议配合心跳（
'ping' => true）或手动探活，不能只靠 break_reconnect
其他干扰因素
有些部署环境会绕过 TP 的连接管理机制。
- 用了 Swoole 或连接池中间件，连接可能跨请求共享，TP 的重连只作用于当前连接对象，无效
- 配置了
PDO::ATTR_PERSISTENT => true（持久连接），会导致 break_reconnect 失效——PDO 层接管连接，TP 无法干预 - debug 关闭且没配日志，重连成功也看不到提示，误以为没生效；开启
'debug' => true或查日志确认是否有reconnect success
不复杂但容易忽略。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
