“MySQL server has gone away”错误主因是MySQL的wait_timeout与PHP连接空闲时间不匹配，需修改MySQL配置而非php.ini；确认方法为执行SHOW VARIABLES LIKE 'wait_timeout'；修复优先级：连接后SET SESSION、改my.ini中wait_timeout、避免长连接复用。
phpEnv 环境下出现 “MySQL server has gone away” 错误，绝大多数不是 phpEnv 本身的问题，而是 MySQL 的 wait_timeout 与 PHP 连接行为不匹配导致的——你改了 phpEnv 的 PHP 配置，但没动 MySQL 的连接超时逻辑，就白调。
为什么 phpEnv 里改了 php.ini 没用？
phpEnv 是 Windows 下的 PHP 环境管理工具，它只管 PHP 进程和扩展（如 mysqli、PDO_MySQL），不管 MySQL 服务本身的配置。很多人在 phpEnv 的 php.ini 里狂加 default_socket_timeout 或 mysql.connect_timeout，结果错误照出——因为这些参数控制的是「建立连接」或「读取响应」阶段的超时，而 MySQL server has gone away（错误码 2006）90% 是连接建好后空闲太久，被 MySQL 服务端主动踢掉，跟 PHP 的 socket 超时无关。
-
default_socket_timeout影响的是 PHP stream 层读写等待（比如大字段读取卡住），默认 60 秒；但它不会阻止 MySQL 服务端在 30 秒后直接断连 -
mysqli.reconnect = On在 phpEnv 的 php.ini 里设了也基本无效：PHP 官方明确说明，mysqli扩展自 PHP 5.5+ 起已废弃该选项，且即使开启也不处理空闲断连 - phpEnv 启动的 MySQL 服务（如果自带）通常用的是默认配置，
wait_timeout很可能仍是 28800（8 小时），但某些精简版或一键包会悄悄改成 30–60 秒，必须查证
怎么确认是 wait_timeout 导致的？
别猜，直接进 MySQL 查当前连接的实际超时值。用 phpEnv 自带的 MySQL 客户端（或命令行）执行：
mysql -u root -p SHOW VARIABLES LIKE 'wait_timeout'; SHOW VARIABLES LIKE 'interactive_timeout'; SHOW PROCESSLIST;
重点看三件事：
立即学习“PHP免费学习笔记（深入）”；
- 如果
wait_timeout显示是 30 或 60，基本就是它 —— phpEnv 自带的 MySQL 常被魔改过 - 你的 PHP 连接在
SHOW PROCESSLIST里Time列持续增长，快到wait_timeout值时断开，就是铁证 -
interactive_timeout值再大也没用：PHP 的mysqli_connect()和PDO创建的是非交互式连接，只认wait_timeout
phpEnv 环境下最稳的修复方式
优先级从高到低，推荐按顺序试：
- 连接成功后立刻执行
SET SESSION wait_timeout = 28800：对mysqli是$mysqli->query("SET SESSION wait_timeout = 28800")；对PDO是$pdo->exec("SET SESSION wait_timeout = 28800")。这招绕过所有配置文件限制，100% 生效 - 修改 phpEnv 管理的 MySQL 配置文件：找到 phpEnv 安装目录下的
mysql\my.ini（不是 PHP 的 php.ini），在[mysqld]段下加两行：wait_timeout = 28800和interactive_timeout = 28800，然后重启 MySQL 服务（phpEnv 控制面板里点「重启 MySQL」） - 避免依赖长连接：在 CLI 脚本（如队列、采集）里，不要复用全局
$pdo实例；每次操作前用$pdo->getAttribute(PDO::ATTR_CONNECTION_STATUS)检查，或干脆短连接 + try/catch + 重试
容易被忽略的坑：max_allowed_packet 和 phpEnv 的路径权限
同为 “server has gone away”，但错误源头可能是另一个：当插入或查询超大字段（如 JSON、HTML 片段）时，若超过 MySQL 的 max_allowed_packet 限制，也会报完全一样的错误，且不提示具体原因。phpEnv 默认的 my.ini 里这个值常是 1M 或 4M，不够用。
- 查当前值：
SHOW VARIABLES LIKE 'max_allowed_packet'; - 临时改（重启失效）：
SET GLOBAL max_allowed_packet = 64*1024*1024; - 永久改：在 phpEnv 的
mysql\my.ini的[mysqld]下加max_allowed_packet = 64M，再重启 MySQL - 额外注意：phpEnv 的 MySQL 服务如果是以 Windows 服务方式运行，修改
my.ini后必须用管理员权限重启，否则配置不加载
真正麻烦的不是改哪，而是改完之后忘记验证——务必用 SHOW VARIABLES 和实际跑一次大 SQL 来确认生效。很多问题拖到上线才暴露，就是因为本地测试时没走真实数据量路径。
