phpEnv本身不控制MySQL连接超时，根因在MySQL服务端配置或PHP连接管理；其默认wait_timeout=28800秒仍可能被CLI脚本空闲期触发断连，需修改my.ini中wait_timeout、interactive_timeout和max_allowed_packet并重启服务，同时在代码中捕获SQLSTATEHY000异常重建连接。
直接说结论：phpEnv 本身不控制 MySQL 连接超时，它只是 Windows 下的 PHP + MySQL 环境集成包；报错 MySQL server has gone away 的根因仍在 MySQL 服务端配置或 PHP 应用连接管理逻辑里，phpEnv 只是把默认配置带进来了——而它的 MySQL 默认 wait_timeout 是 28800 秒（8 小时），看似够用，但 CLI 模式下长时间静默的队列/脚本仍会触发断连。
为什么 phpEnv 环境下更容易遇到这个错误
因为 phpEnv 自带的 MySQL 配置文件（通常是 my.ini）往往沿用旧版保守值，且用户极少主动修改。常见组合问题包括：
-
wait_timeout=28800和interactive_timeout=28800看似合理，但 CLI 脚本中一次事务耗时短、间隔长（比如队列每 5 秒拉一次任务，中间无 DB 操作），空闲期就可能超限 -
max_allowed_packet=1M（phpEnv常见默认值），遇到批量INSERT或含TEXT/BLOB字段的语句，哪怕单条 SQL 不大，拼起来也可能超限 - PHP 进程复用连接（如 PDO 持久连接未设
PDO::ATTR_PERSISTENT => false），而phpEnv启动的 MySQL 服务没有自动重连机制
改 phpEnv 的 my.ini 是最直接的生效方式
别绕开配置文件硬扛。找到 phpEnv 安装目录下的 mysql\my.ini（不是 php.ini），在 [mysqld] 段落追加或修改这几项：
-
wait_timeout = 288000（建议设为 80 小时，单位秒） interactive_timeout = 288000-
max_allowed_packet = 64M（比默认大 64 倍，覆盖多数批量场景）
改完必须重启 phpEnv 中的 MySQL 服务（通过托盘图标或服务管理器），否则配置不加载。验证是否生效：用命令行连上 MySQL，执行 SHOW VARIABLES LIKE 'wait_timeout';，确认数值已更新。
立即学习“PHP免费学习笔记（深入）”；
PDO 连接层不能只靠 ping，要结合异常捕获重连
mysqli_ping() 在 PDO 场景下不适用；PDO::getAttribute(PDO::ATTR_CONNECTION_STATUS) 也不可靠。真实有效的方式是：在每次执行前不做预检，而是在 PDOException 抓到 SQLSTATE[HY000] [2006] 时重建连接。
- 不要写
if (! $pdo->connected) { reconnect(); }—— PDO 没有connected属性 - 捕获异常后，应销毁原
$pdo实例，再调用新建连接函数，否则旧句柄残留仍会出错 - 若用 ThinkPHP，直接开
break_reconnect => true即可，它内部已封装了重连+重试逻辑
示例片段（非框架项目）：
try {
$stmt = $pdo->query("SELECT 1");
} catch (PDOException $e) {
if ($e->getCode() === '2006') {
$pdo = new PDO($dsn, $user, $pass, [
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
]);
}
}
CLI 脚本里最容易被忽略的静默空闲点
很多开发者只盯着 SQL 执行时间，却忽略了脚本里「没碰数据库」的等待段落。比如：
- 循环处理数据前，用
sleep(3)等待上游就绪 - 调用外部 API 后未立即操作数据库，而是先做本地计算
- 日志写入、文件读写、缓存检查等 IO 操作期间连接完全闲置
这些都会让连接在 MySQL 侧进入 idle 状态。解决办法不是拉长 timeout，而是主动“心跳”：$pdo->exec("SELECT 1"); 放在长操作前后，成本极低，但能重置服务器端计时器。
