下载中断导致.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 比你本地文件小，说明服务端就没发全；若大但本地小，说明下载中途断了