thinkphp 6 在 php-fpm 模式下 'persistent' => true 或 pdo::attr_persistent 基本无效，因其 connection 类析构时强制置空 $this->pdo 导致 socket 断开，且原生 pdo_mysql dsn 不识别 persistent 参数；真正可用的是 'deploy' => 1 实现单进程内 pdo 实例复用，而连接池仅限 swoole 环境并通过 think-swoole 配置。
在 ThinkPHP 6 中，database.php 里配 'persistent' => true 或 'params' => [PDO::ATTR_PERSISTENT => true]，对 PHP-FPM 模式基本无效——不是配置错了，而是框架连接销毁逻辑和 PDO DSN 解析机制共同绕过了它。
为什么 persistent 在 TP6 的 FPM 下几乎不起作用
TP6 的 Connection 类在析构时强制执行 $this->pdo = null，PDO 对象一销毁，底层 socket 就断开，PDO::ATTR_PERSISTENT 根本没机会生效。更关键的是，MySQL 的原生 pdo_mysql（非 mysqlnd）DSN 不识别 persistent 参数；即使你用的是 mysqlnd，TP6 官方也未维护 mysqli 驱动，'persistent' => true 写在配置里只是被忽略。
常见错误现象包括：
-
SHOW PROCESSLIST看不到复用连接，每个请求都新建一个Command: Sleep连接 - QPS 上去后仍报
Too many connections，连接数随并发线性增长 - CLI 脚本运行超时后，复用连接直接失败，报
MySQL server has gone away
TP6 真正可用的连接复用方案：deploy=1 + pool 配置仅限 Swoole 环境
TP6 官方没有连接池实现，database.php 中的 'pool' => ['max' => 20] 等配置项，在标准 FPM 模式下完全不生效——它只对 Swoole、Workerman 等常驻进程环境有效，且需手动集成 topthink/think-swoole 才能触发。
如果你确实在用 Swoole：
- 必须启用
'deploy' => 1，这是 TP6 内置连接复用开关，靠框架自己缓存已建立的 PDO 实例 -
'pool_size'和'pool_time'才会起作用，但要注意与 MySQL 服务端的max_connections匹配，否则代理或框架层先扛不住 - 避免混用
'persistent' => true，它和deploy=1的复用逻辑冲突，可能引发状态污染（如事务未回滚、字符集残留）
FPM 模式下该怎么做：别碰 persistent，转而控制连接生命周期
FPM 下每次请求都是全新进程，所谓“长连接”只能退化为“单进程内复用”，核心目标是减少 new PDO() 次数，而不是维持 socket 不断开。
实操建议：
- 避免在循环或命令行任务中反复调用
Db::connect()，改用一次连接多次查询；必要时显式调用Db::close()释放连接 - 确认
'break_reconnect' => true已开启，防止单次查询失败卡死整个连接实例 - 把
max_connections、wait_timeout和pm.max_children三者对齐：例如 FPM 开了 64 个 worker，MySQL 就至少设max_connections = 128（留冗余），wait_timeout ≥ 300 - 禁用
app_debug = true和log_write_mode = 3，它们会延长请求生命周期，间接拉长连接占用时间
真正要警惕的不是配置失效，而是状态残留
哪怕 persistent 偶尔生效了，也会带来更隐蔽的问题：事务未提交、临时表未清理、用户变量残留、字符集错乱——这些不会立刻报错，但会在后续请求中随机触发数据异常或查询失败。
比“连不上”更麻烦的是“连上了但结果不对”。FPM 模式下，与其强求复用，不如确保每次连接干净初始化、及时关闭、出错可重试。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
