ThinkPHP MySQL连接超时需分层设置：PDO层用'params'=>[PDO::ATTR_TIMEOUT=>3]控制TCP连接超时，MySQL服务端wait_timeout影响空闲断连，须配'break_reconnect'=>true；多连接需各配置独立声明，CLI需同步php.ini default_socket_timeout，且PDO错误模式应设为EXCEPTION以便精准捕获超时异常。
ThinkPHP 连接 MySQL 超时怎么设？
连接超时不是靠 timeout 字段随便填个数字就生效的——ThinkPHP 里它分两层：PDO 底层连接建立超时（connect_timeout），和查询执行超时（wait_timeout，由 MySQL 服务端控制）。你改了配置却没效果，大概率是只动了其中一层。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在数据库配置数组中显式加
'params' => [\PDO::ATTR_TIMEOUT => 3]，这是 PDO 建立 TCP 连接的秒级超时，值太小（如 0.5）可能误杀正常慢连，太大（如 30）等于没设 -
'deploy' => 0模式下，'host'必须写真实 IP，不能写localhost（否则会走 socket，绕过connect_timeout） - MySQL 服务端的
wait_timeout默认 28800 秒（8 小时），但 ThinkPHP 长连接复用时，如果中间空闲太久，连接会被 MySQL 主动断开，下次用就报MySQL server has gone away—— 这时候要配'break_reconnect' => true
为什么开了 break_reconnect 还卡死？
这个选项只对「查询执行中连接断开」有效，不处理「连接根本建不上」的场景。比如 MySQL 宕了、防火墙拦了、DNS 解析失败，PDO 会卡在 mysql_real_connect() 直到系统 TCP 超时（Linux 默认 75 秒），ThinkPHP 拦不住。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 必须配合
'params' => [\PDO::ATTR_TIMEOUT => 5]使用，否则break_reconnect不触发 - 不要依赖
try/catch包裹Db::table()->select()来兜底——连接失败发生在查询前，异常抛在new PDO()那一刻，得在初始化数据库实例时捕获 - 生产环境建议加
'debug' => false，否则连接失败时 PDO 会输出冗长错误堆栈，掩盖真正超时原因
多应用/多数据库下超时配置容易漏哪？
ThinkPHP 的数据库配置是按「连接名」隔离的，database.php 里默认的 'default' 配置不会自动继承给其他连接；如果你用 Db::connect('log')，就必须在 'log' 对应配置里单独写 'params' 和 'break_reconnect'，复制粘贴时很容易漏掉 ATTR_TIMEOUT。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 所有自定义连接配置里，检查是否含
'params' => [\PDO::ATTR_TIMEOUT => 3]和'break_reconnect' => true，缺一不可 - 避免用
Db::connect(['dsn' => '...'])临时创建连接——这种写法无法设置ATTR_TIMEOUT，PDO 默认用 0（无限等待） - CLI 命令行运行时，PHP 的
default_socket_timeoutini 设置也会影响连接，建议统一设为5，和 PDO 层对齐
查不到超时日志？先看 PDO 错误模式
PDO 默认是 PDO::ERRMODE_SILENT，连接失败只返回 false，不抛异常，日志里就只剩一句「SQLSTATE[HY000] [2002]」，看不出是超时还是密码错。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在数据库配置中加
'params' => [\PDO::ATTR_ERRMODE => \PDO::ERRMODE_EXCEPTION]，这样超时会明确抛出PDOException，消息带Connection refused或Operation timed out - 别信
ini_get('mysqli.connect_timeout')—— ThinkPHP 用 PDO，跟 mysqli 配置无关 - 用
strace -e trace=connect,sendto,recvfrom php index.php可直接看到系统调用级超时点，比看日志快得多
超时不是设一个数就完事，它是 PDO 参数、MySQL 服务端配置、网络环境、ThinkPHP 连接池策略四者咬合的结果。最容易被忽略的是：本地开发时一切正常，一上容器或云数据库，DNS 解析延迟或安全组策略会让连接卡在第一步，而你还在查 SQL 写得对不对。
