下载中断导致.gz文件“看似完整”实则损坏，验证需三步：先用file或head检查魔数1f8b确认gzip格式；再用gzip -t校验压缩流完整性；最后比对官方提供的大小或sha256哈希值，并通过curl -i核对content-length等响应头确保服务端未篡改。
下载中断后，.gz 文件往往只是“看起来完整”——文件存在、有 .gz 后缀、甚至能打开，但实际缺少末尾字节，导致解压失败或静默损坏。验证重点不是“能不能解压”，而是“是否传输完整”。
看文件头和魔数，确认它真是 gzip 格式
gzip 文件开头固定是 2 字节魔数 1f 8b。只要这俩字节不对，就不是合法 gzip 流，后续校验全无意义。
- 运行：
head -c 2 yourfile.gz | xxd，输出应为00000000: 1f8b ... - 或者更直接：
file yourfile.gz，正确输出类似yourfile.gz: gzip compressed data... - 如果显示
ASCII text或data，说明根本不是 gzip，可能是下载跳转页（如 302 HTML）、空响应或中间代理截断的残留
测压缩流完整性，用 gzip 自带工具
gzip 提供了轻量、可靠的校验方式，不依赖外部哈希，直接验证压缩结构本身是否可解码。
- 运行：
gzip -t yourfile.gz - 成功：无输出，返回码为 0
- 失败：提示
unexpected end of file或invalid compressed data，说明流被截断或损坏 - 注意：这个命令只检查压缩层，不验证原始内容是否正确；但它能最快暴露网络中断导致的“半截文件”
比对大小与哈希，锁定是否下载完整
官方通常会提供 .gz 文件的原始大小或 SHA256 值。这是最客观的完整性依据。
- 查预期大小：
ls -l yourfile.gz→ 对比官网或发布页标注的字节数（例如 12.4 MB = 13000000 字节） - 算 SHA256：
sha256sum yourfile.gz→ 和发布页的 checksum 字符串逐字符比对（注意大小写和空格） - 若大小明显偏小（差几 KB 以上），基本可判定下载中断；若大小一致但
gzip -t失败，则可能是磁盘写入异常或代理缓存污染
抓响应头，确认服务端没偷偷改内容
有些 CDN 或反向代理会在传输中修改响应体（如自动 gzip、注入脚本、截断大响应），导致客户端拿到的 .gz 实际已被篡改。
- 用 curl 重放下载请求：
curl -I https://example.com/file.gz - 检查关键头：
Content-Length（应等于你本地文件字节数）、Content-Encoding: gzip（确认服务端真发了 gzip）、ETag或Last-Modified（辅助判断是否缓存污染） - 若
Content-Length比你本地文件小，说明服务端就没发全；若大但本地小，说明下载中途断了
