mysql连接超时导致“server has gone away”错误，应启用break_reconnect和check_conn自动重连与预检，禁用persistent避免状态污染，合理设置wait_timeout为300～600秒。
MySQL 连接超时后 thinkphp 报 SQLSTATE[HY000] [2006] MySQL server has gone away
这是最常见现象：请求处理时间稍长（比如导出、大查询、sleep 模拟），或连接空闲超过 wait_timeout，PDO 就会复用一个已断开的连接，直接报错。ThinkPHP 默认不校验连接有效性，只管用。
解决思路不是“加长 timeout”，而是让连接在使用前自检是否还活着：
- 在数据库配置中开启
'break_reconnect' => true（TP6.0+），它会在 PDO 报错后自动重连一次 - 更稳妥的做法是配合
'deploy' => 0（单库模式） +'check_conn' => true（TP6.3+ 新增），后者会在每次获取连接时执行PDO::getAttribute(PDO::ATTR_SERVER_INFO)做轻量探测 - 避免在事务中跨长时间操作——
beginTransaction()后如果 sleep(30)，连接大概率已断，后续commit()必然失败
TP6 的 connection 配置里要不要设 'persistent' => true
不要。PHP-FPM 下开启长连接（persistent）反而容易引发连接泄漏和状态污染。每个 FPM worker 进程会缓存自己的 PDO 实例，但 ThinkPHP 的连接池管理逻辑并未完全适配持久化连接的生命周期，容易出现：
- 事务未正确 rollback，下个请求复用该连接时读到脏数据
- 字符集、时区等 session 级设置残留，影响后续查询
- MySQL 报
Too many connections，但SHOW PROCESSLIST显示大量Sleep连接，实际是 FPM 进程没释放
真实高并发场景下，连接池收益远大于持久化连接——用 'pool_size' => 20（需配合 'deploy' => 1 或独立配置多个节点）更可控。
手动管理连接池：什么时候该调 Db::close()？
绝大多数情况不用主动关。ThinkPHP 在 Request 生命周期结束时会自动释放连接（包括连接池归还）。但以下两个场景必须干预：
- CLI 命令中循环处理大批量数据（如每批 1000 条），不关连接会导致连接数线性增长，最终触发 MySQL 限制——应在每批处理完后调
Db::close() - 使用了
Db::connect()手动指定配置创建连接，且该连接仅用于临时任务（如对接第三方 DB），务必在任务结束后显式调$conn->close()，否则它不会进默认连接池，也不会被自动回收
注意：Db::close() 关的是当前默认连接；若用了 Db::name('user')->connect('other')，要先切回再关，或直接保存连接对象调 close()。
wait_timeout 和 interactive_timeout 该调哪个？
调 wait_timeout 就够了。ThinkPHP 使用的 MySQL 连接默认是非交互式（CLIENT_INTERACTIVE 未启用），所以生效的是 wait_timeout（默认 28800 秒 = 8 小时）。
但别盲目调大。设成 24 小时看似保险，实际会让失效连接滞留更久，连接池命中率下降，还可能掩盖应用层连接未释放的问题。合理值是：
- Web 请求场景：300～600 秒（5～10 分钟），匹配 PHP
max_execution_time和 Nginxproxy_read_timeout - CLI 场景：按任务最长耗时 + 60 秒冗余，比如导出脚本预计跑 1200 秒，就设
wait_timeout = 1260
改完记得重启 MySQL，且要确认应用侧没有用 mysql_set_charset 类旧函数绕过 PDO，否则配置可能不生效。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
