thinkphp连接池报错本质是连接复用机制与mysql wait_timeout、pdo超时配置缺失或连接泄漏冲突所致；高频“mysql server has gone away”表明服务端主动断连，需配break_reconnect和pdo::attr_timeout，并检查连接是否未释放或未正确注册入池。
ThinkPHP 连接池报错本质不是“连接池”本身出问题，而是连接复用机制撞上了 MySQL 的 wait_timeout、PHP 的 PDO::ATTR_TIMEOUT 配置缺失，或连接泄漏没释放——直接查日志里是否反复出现 MySQL server has gone away 或 Connection lost 就能快速定位。
查日志先看是不是 MySQL server has gone away 错误
这个错误几乎 90% 是 MySQL 主动断开了空闲太久的连接，而 ThinkPHP 拿着已失效的连接继续用导致的。它和“连接池满”看起来像，但根源完全不同。
- 打开
runtime/log/下最近的错误日志，搜索MySQL server has gone away；如果高频出现，说明连接被服务端回收了，不是连接数不够 - 检查 MySQL 当前
wait_timeout值：SHOW VARIABLES LIKE 'wait_timeout';，默认是 28800 秒（8 小时），但某些云数据库（如阿里云 RDS）会设成 300 秒 - 若值很小（比如 60 或 300），必须配
'break_reconnect' => true，否则 ThinkPHP 不会自动重连 - 注意：仅配
break_reconnect不够，还必须同时设置'params' => [\PDO::ATTR_TIMEOUT => 5]，否则 PDO 在建立新连接时可能卡死在系统级 TCP 超时（Linux 默认 75 秒）
too many connections（1040 错误）真要调 MySQL 最大连接数
这个才是连接池“满了”的真实信号，但别急着改 MySQL 配置——先确认是不是应用层在疯狂创建新连接却没释放。
- 查当前 MySQL 连接数：
SHOW STATUS LIKE 'Threads_connected';，再对比SHOW VARIABLES LIKE 'max_connections'; - 如果
Threads_connected接近max_connections（比如 150/151），且持续不降，大概率是模型里写了Db::connect()却没复用、或事务/闭包中没正确关闭 - ThinkPHP 5.1+ 默认不复用连接，除非显式使用
Db::connect('default')并缓存返回对象；用db()助手函数每次都会新建连接 - 临时调高 MySQL 限制可解燃眉之急：
SET GLOBAL max_connections = 500;，但更稳妥的是改配置文件my.cnf加max_connections = 500并重启 MySQL - 别只盯着 MySQL，PHP-FPM 的
pm.max_children也得匹配——如果 PHP 进程数设成 100，每个进程最多持 10 个连接，那 MySQL 至少要开到 1000
连接池配置漏写 PDO::ATTR_TIMEOUT 是最常见坑
ThinkPHP 的数据库配置里，timeout 字段是无效的，真正起作用的是 params 数组里的 PDO::ATTR_TIMEOUT，而且它只在连接建立阶段生效。
- 在
config/database.php的每个连接配置（包括default和自定义名如log）里，都必须单独加：'params' => [\PDO::ATTR_TIMEOUT => 3] - 值设成 3 秒比较合理：太小（如 0.5）容易把正常网络延迟判为超时；太大（如 30）等于没设，PDO 会等系统级超时
- 注意：TP6 中如果手动写了
dsn字段，params会被忽略，必须把timeout写进 DSN 里，例如mysql:...;connect_timeout=3; - CLI 环境下还要同步检查
php.ini的default_socket_timeout，否则命令行跑队列时也会卡住
多连接场景下 Connection not found 其实是连接池没注册
报这个错不是连接池坏了，是 ThinkPHP 根本没把你的连接配置加载进连接池管理器，所以 Db::connect('log') 找不到。
- 确保
config/database.php里'connections'数组（或顶层键）中，连接名（如'log'）和Db::connect('log')的字符串完全一致，大小写敏感 - 如果连接配置是运行时从数据库读取的，不能只 new 一个数组，必须调
Db::setConfig($config, 'log')注入，否则不会进池 - 别依赖
db()切换连接——它只认default，db('user', ['connection' => 'log'])这种写法在 TP5.1 中不生效，必须用Db::connect('log')->name('user') - 检查是否在模型
initialize()里反复调Db::connect()却没赋值给属性，造成每次请求新建连接、池子越积越多
真正难排查的是连接泄漏：它不报错，但连接数缓慢上涨，直到某次并发触发 1040。重点盯 Transaction、try/catch 块里的 Db::close() 调用，以及是否在闭包里用了未绑定生命周期的连接实例。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
