ThinkPHP数据库连接“2006”错误：从根源到实战的稳定重连方案
在ThinkPHP项目中，你是否遇到过这样的场景：一个长时间空闲的数据库连接，突然在下一次查询时报错——SQLSTATE[HY000] [2006] MySQL server has gone away。这通常意味着MySQL服务器已经主动断开了空闲超时的连接。别担心，这个问题有成熟的解决方案。下面这几种经过验证的配置方法，能帮你稳定地实现断线重连，让应用恢复如初。
一、启用框架内置break_reconnect机制
ThinkPHP其实自带了一套连接恢复能力。它的原理是，当捕获到特定的PDO网络异常时，框架会自动关闭失效连接并尝试建立新连接。不过要注意，它只对PDO::ERRMODE_EXCEPTION模式下产生的网络类错误（比如2006）有效，如果是SQL语法错误或者在事务中途断开，它就无能为力了。
具体配置起来很简单：
首先，打开数据库配置文件config/database.php，找到你正在使用的数据库连接配置（比如mysql）。
接着，确认'type'的值是'pdo_mysql'。这一点很重要，因为mysqli或老的mysql驱动并不支持这个特性。
然后，将配置项'break_reconnect'的值设置为true。
同时，别忘了在'params'数组里显式地加上PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，确保错误以异常形式抛出。
为了更精准地匹配断线错误，你还可以添加'break_match_str' => ['2006', 'Error while sending']这样的配置。
最后，记得确认'debug' => true或者已经开启了日志记录，否则重试过程可能悄无声息，不利于排查。配置完成后，重启你的Web服务或CLI进程，让改动生效。
二、CLI环境独立启用重连（规避FPM风险）
如果你的应用同时有Web请求（FPM）和后台队列、命令行（CLI）任务，并且共用一套数据库配置，那么全局开启break_reconnect就得小心了。在FPM环境下，这可能会意外中断事务的语义。一个更稳妥的方案是，只在CLI环境下动态启用重连。
具体做法是，在队列启动脚本或者自定义命令的入口文件顶部，引入数据库配置。
然后，通过$dbConfig = config('database.connections.mysql');获取当前的配置数组。
接着，手动将这个配置数组中的'break_reconnect'项设置为true。
最关键的一步，调用\think\Db::init($dbConfig);，用修改后的配置重新初始化数据库连接实例。
这样，后续所有通过Db类执行的操作，都会基于这个启用了重连功能的新实例。这个方法的好处是无需改动全局配置文件，尤其适合ThinkPHP-Queue这类长驻进程的场景。
三、配合Swoole常驻进程的手动探活重连
在Swoole的Worker或Task进程这类长生命周期环境里，框架级别的break_reconnect可能会失效，因为它通常设计为在单次请求-响应周期内生效。这时候，我们需要更主动的策略：在连接被MySQL服务器断开之前，就通过心跳探活来发现并重建连接。
首先，在Swoole Server的onWorkerStart事件回调里初始化数据库连接。
然后，利用Timer::tick()设置一个周期性的定时器，比如每3000毫秒执行一次心跳检测。
在定时器的回调函数中，执行一条简单的查询，例如Db::query('SELECT 1')，来验证连接是否健康。
如果这条查询抛出了\PDOException异常，并且错误信息里包含2006或Broken pipe这类关键词，那就说明连接已经断了。这时，立即执行Db::close()强制关闭当前的无效连接。
这样一来，下一次业务查询时，框架就会自动建立一个全新的连接，而不必等到查询失败后才触发重试。这个方案绕过了框架的一些默认限制，是Swoole与ThinkPHP混合部署时的有效选择。
四、调整MySQL服务端参数协同优化
俗话说，解铃还须系铃人。光靠客户端重连是治标，要想治本，还得从MySQL服务器端入手。我们需要调整服务器的空闲超时参数，让它和应用程序的心跳或任务执行节奏相匹配，从而缩小“连接已断但客户端还不知道”这个危险的时间窗口。
首先，登录MySQL服务器，执行SHOW VARIABLES LIKE 'wait_timeout';命令，查看当前的超时设置。
如果这个值比较大（比如超过300秒，即5分钟），那么建议将它调低到300或600，以便更好地匹配PHP CLI任务的执行间隔。
你可以通过SET GLOBAL wait_timeout = 300;命令临时修改（需要SUPER权限）。
要想永久生效，则需要编辑MySQL的配置文件my.cnf，在[mysqld]段落中添加一行：wait_timeout = 300。
修改后，重启MySQL服务或者执行FLUSH PRIVILEGES;让配置加载。另外，也可以同步检查一下interactive_timeout的值，不过对于CLI进程，主要受wait_timeout控制。
五、事务场景下的安全重试封装
事务，是断线重连中的一个特殊难点。框架默认不会在事务中自动触发重连，原因很简单：一旦重连，之前的事务上下文就丢失了，强行继续操作只会引发“There is no active transaction”错误。因此，事务内的安全重试，必须由业务逻辑层来显式控制。
一个可行的方案是，将核心的事务操作包裹在一个for循环内，并设置一个最大重试次数，比如3次。
每一次循环开始时，都使用Db::transaction(function() { ... });开启一个全新的事务。
在事务执行过程中，捕获\think\db\exception\PDOException异常，并检查错误信息是否包含2006。
如果捕获到的是断线错误，并且重试次数还没用完，就进入下一次循环，重新开始整个事务。如果重试了3次仍然失败，则不再捕获，将原始异常抛出，交由上层处理。
还有一个小技巧：每次重试之前，可以插入一个短暂的延迟，比如usleep(100000)（即100毫秒），这能避免在瞬间发生大量重试，给数据库造成压力。需要明确的是，这套事务重试逻辑需要开发者根据业务自行封装，框架目前并没有提供通用的组件。
