GZIP导出失效是因服务端压缩未真正生效，而非文件损坏；常见于数据量过小等场景，导致生成的并非合法gzip流。
不是文件损坏，而是导出过程被截断或压缩未真正生效——你拿到的可能根本就不是合法 gzip 流。
导出时勾了 GZIP 但实际没压缩
phpMyAdmin 的 GZIP 压缩是服务端 PHP 动态生成的，不是简单加个后缀。常见失效场景包括：
- 数据量太小（比如 .sql.gz 后缀，但内容是明文 SQL，用
gunzip解压会报not in gzip format - PHP 的
zlib扩展未启用：运行phpinfo()查看是否有zlib模块，没有就无法压缩 - 配置禁用了压缩：
config.inc.php中设置了$cfg['EnableGzipDump'] = false;，勾选也无效 - 导出中途超时或浏览器断连，PHP 进程终止，但浏览器仍收到一个残缺的
.gz文件头（如\x1f\x8b开头），后续字节为空或乱码
解压时报 “unknown compression format” 或 “premature end of file”
这类错误往往指向文件不完整，而非解压工具问题：
- 用
file backup.sql.gz命令检查真实类型：如果返回POSIX tar archive或ASCII text，说明根本没压缩 - 用
gzip -t backup.sql.gz验证完整性：报unexpected end of file就是传输中断导致截断 - Mac 用户尤其注意：系统归档实用工具对非标准 gzip 兼容差，别双击，改用终端
gunzip或zcat测试
导入前误操作让 .gz 文件“变质”
有些用户为绕过 phpMyAdmin 导入限制，手动把 .sql.gz 改名为 .sql 再上传——这不会触发解压，反而让 MySQL 客户端直接读二进制流，报错 Unknown command '\x1f'。更隐蔽的问题是：
- 用文本编辑器（如 VS Code、Sublime）打开并保存过
.gz文件：哪怕只光标移动一下，也可能破坏二进制结构 - 通过邮件或某些云盘同步时被转码：部分服务会对附件做自动扫描/重编码，gzip 流极易损坏
- Windows 资源管理器右键“发送到 → 压缩文件夹”二次打包：生成的是 ZIP，不是 GZIP，后缀混淆导致误判
真正要确认是否有效压缩，只看两点：文件头必须是 \x1f\x8b（用 xxd -l 4 backup.sql.gz 查），且 gzip -t 不报错。其他所有“看起来像 .gz”的情况，都得先验证再操作。
立即学习“PHP免费学习笔记（深入）”；
