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