MySQL连接超时丢失主因是max_allowed_packet过小或wait_timeout/interactive_timeout设置不当，需同步调大并重启MySQL验证生效。
MySQL 连接超时丢失的典型表现
页面报错
或
，尤其在上传大文件、执行长事务、导出大表时高频出现。这不是网络断开，而是 MySQL 主动中断了“太久没动静”或“数据包太大”的连接。
max_allowed_packet 设置不对会直接触发断连
当客户端（比如 PHP 的 mysqli 或 PDO）尝试发送超过
的 SQL（如含大 blob 字段的 INSERT）、或接收超长查询结果时，MySQL 会静默关闭连接——不返回错误，只丢包。宝塔默认值常为 4M，远低于现代 CMS 上传附件或生成报表的需求。
检查当前值：
临时生效（重启失效）：
（即 64M）
永久生效：编辑 MySQL 配置文件（宝塔中路径通常是
），在
下加一行：
注意：PHP 的
和
也得同步调大，否则请求根本到不了 MySQL
wait_timeout 和 interactive_timeout 控制空闲连接寿命
宝塔环境里，PHP-FPM 常复用 MySQL 连接，但若连接空闲时间超过
（默认 28800 秒，即 8 小时），MySQL 会主动 kill 掉它。而 PHP 再次使用这个已失效的连接句柄，就报 “has gone away”。
查当前值：
推荐设为 300（5 分钟）：
和
（写进
的
段）
为什么不是设更大？因为短超时 + 应用层重连比长超时 + 偶发断连更可控；且宝塔下多数网站并发不高，5 分钟足够覆盖正常用户操作间隙
PHP 侧别用长生命周期的
（已废弃），优先用 PDO 并开启
，方便捕获后重建连接
宝塔面板里改完配置不生效的常见原因
改完
忘重启 MySQL 是最常见失误；另外，宝塔可能读取的是备用配置路径，或被 Docker/快照环境覆盖。
必须执行：
（或在宝塔「软件商店」里点 MySQL 的「重启」按钮）
确认生效：登录 MySQL 后再运行
和
，看数值是否更新
如果值没变，检查是否改错了文件——宝塔有时会把配置拆成
+
，优先级高的配置会覆盖低的
修改后观察 24 小时内错误日志（
），重点搜
，确认是否还有因超时或包大小导致的强制断连
实际调参时，
和
得一起动，光调一个解决不了“断连”这个复合症状；而且所有改动必须验证是否真正加载，不然白忙活。
Lost connection to MySQL server during queryMySQL server has gone awaymax_allowed_packetSHOW VARIABLES LIKE 'max_allowed_packet';SET GLOBAL max_allowed_packet = 64*1024*1024;/www/server/mysql/my.cnf[mysqld]max_allowed_packet = 64Mpost_max_sizeupload_max_filesizewait_timeoutSHOW VARIABLES LIKE '%timeout%';wait_timeout = 300interactive_timeout = 300my.cnf[mysqld]mysql_connect()PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTIONmy.cnf/etc/init.d/mysqld restartSHOW VARIABLES LIKE 'max_allowed_packet';SHOW VARIABLES LIKE 'wait_timeout';my.cnfconf.d/*.cnf/www/server/mysql/logs/error_logAborted connectionmax_allowed_packetwait_timeout