在phpEnv中修改MySQL的max_allowed_packet需编辑phpEnv\MySQL\my.ini文件的[mysqld]段，设max_allowed_packet = 64M，改后须手动重启MySQL服务（杀掉mysqld.exe再启动），并验证SELECT @@global.max_allowed_packet；PHP连接后还需执行SET SESSION max_allowed_packet确保生效。
phpEnv 里 MySQL 的 max_allowed_packet 改哪里？
phpEnv 是 Windows 下的集成环境，MySQL 配置文件默认在 phpEnv\MySQL\my.ini（不是 my.cnf），必须改这个文件里的 [mysqld] 段，其他位置无效。常见误区是去改 PHP 目录下的配置，或误以为改了 php.ini 就管用——完全不相关。
打开 phpEnv\MySQL\my.ini，找到 [mysqld] 区块，在它下面新增一行：
max_allowed_packet = 64M
注意：64M 合法，64MB 或 64*1024*1024 会报错；不能写在 [client] 或 [mysql] 段下，那只是客户端工具自己的限制，不影响 phpEnv 中 PHP 连接 MySQL 的行为。
改完不生效？先看服务有没有真重启
phpEnv 界面点“重启 MySQL”经常只是发了个软信号，未必真正 reload 配置。最可靠的方式是：在 phpEnv 控制台里手动停止 MySQL，再手动启动——或者直接进任务管理器杀掉所有 mysqld.exe 进程，再点启动。
立即学习“PHP免费学习笔记（深入）”；
验证是否生效，别信界面或文件，连上去查：
SELECT @@global.max_allowed_packet, @@session.max_allowed_packet;
如果 @@global 还是 4194304（即 4MB），说明没重启成功；如果 @@session 明显更小（比如还是 4MB），说明 PHP 连接时被覆盖了——常见于 PDO 或 mysqli 连接字符串里硬编码了低值，或用了旧版 phpEnv 自带的连接池脚本。
PHP 侧也要同步检查连接参数
即使 MySQL 服务端设成了 64M，PHP 默认用的 MySQLi 或 PDO 连接仍可能受限。尤其是以下几种情况：
- mysqli_connect() 第五个参数传了
MYSQLI_CLIENT_COMPRESS之类，但没显式控制包大小 - PDO DSN 中漏了
&maxAllowedPacket=67108864（JDBC 风格参数对 PDO 无效，PDO 不认这个） - 用了 phpEnv 自带的
config.inc.php或封装类，里面调了mysqli_options($link, MYSQLI_OPT_MAX_ALLOWED_PACKET, 4194304)
稳妥做法：在 PHP 脚本连接后立刻执行
mysqli_query($link, "SET SESSION max_allowed_packet = 67108864");
或 PDO 方式：
$pdo->exec("SET SESSION max_allowed_packet = 67108864");
这能绕过大部分连接层覆盖，且只影响当前请求。
存 Base64 或大 JSON 时容易踩的坑
很多人以为把 max_allowed_packet 设到 256M 就能稳存一张 200MB 的 Base64 图片——实际会失败，因为：
- Base64 编码后体积膨胀约 33%，原始 150MB 文件 → Base64 后超 200MB，再加 SQL 语法开销（INSERT 字符、引号、转义），很容易突破上限
- phpEnv 默认的 MySQL 版本（如 5.7.31）对 >128MB 的 packet 有内存对齐 bug，偶尔触发崩溃或连接卡死
- PHP 自身的
post_max_size和upload_max_filesize早就在前端拦住了，根本传不到 MySQL 这一层
真正该做的：前端上传前压缩图片；后端用 file_put_contents() 存文件系统，数据库只存路径；非得存库就用 LONGBLOB + 分片逻辑，而不是靠堆高 max_allowed_packet。
