Go gzip 为什么生成文件无法解压

不少朋友在用Go编写gzip压缩逻辑时，经常会碰到生成的.gz文件无法正常打开、解压直接报错的问题，这类异常绝大多数都和压缩流的处理逻辑疏漏有关。

gzip生成文件无法解压的核心常见原因是gzip.Writer没有正常调用Close()方法完成尾流写入，或是字节流写入时拼接顺序出错导致文件头/尾校验不通过。

Go 用 compress/gzip 生成的文件无法解压，最常见原因不是压缩级别，而是写入流程没有完整结束：gzip.Writer.Write 只负责提交压缩数据，gzip.Writer.Close 才会把尚未写出的内容和 GZIP footer 写入底层文件。正确顺序是“写入成功 → 关闭 gzip.Writer → 关闭 os.File”，并且两个关闭操作都要检查错误。

Go gzip 文件为什么看似写成功却无法解压

GZIP 文件可以看成三段：头部、压缩数据和尾部。尾部包含未压缩数据长度与 checksum。gzip.NewWriter 创建的是带缓冲的 io.WriteCloser；Write 返回成功，只代表这次输入已被压缩器接收，不代表所有字节已经落到文件中。

如果函数在 Write 后直接返回，或者只调用了 Flush 而没有 Close，文件可能只有头部和部分压缩流。解压工具通常会提示 unexpected EOF、unexpected end of file 或格式损坏。Flush 更适合压缩网络协议中尽快发送一个可继续读取的片段，不能替代文件写入的最终 footer。

生成文件的可靠写法：先关 gzip，再关文件

下面的函数把错误处理放在真正可能失败的边界上。特别注意 defer file.Close() 只能负责释放文件句柄，不能替代 gz.Close()；gzip 层必须先关闭，才能把最后的数据写入文件。

package main

import (
    "compress/gzip"
    "fmt"
    "os"
)

func writeGZIP(path string, data []byte) (err error) {
    // 先创建底层文件；后续 gzip.Writer 的所有输出都会写到它。
    file, err := os.Create(path)
    if err != nil {
        return err
    }
    defer func() {
        // 这里只负责关闭文件，gzip 收尾错误由下面的显式 Close 返回。
        if closeErr := file.Close(); err == nil && closeErr != nil {
            err = closeErr
        }
    }()

    gz := gzip.NewWriter(file)
    // Write 只把输入交给压缩器，仍要检查写入错误。
    if _, err = gz.Write(data); err != nil {
        _ = gz.Close()
        return err
    }
    // Close 会刷新剩余压缩数据并写入 GZIP footer，不能省略。
    if err = gz.Close(); err != nil {
        return err
    }
    return nil
}

func main() {
    if err := writeGZIP("report.txt.gz", []byte("hello gzip\n")); err != nil {
        // 生成阶段的错误要阻止调用方把半成品当成可下载文件。
        fmt.Println("write gzip:", err)
    }
}

如果文件系统、磁盘配额或网络文件系统在收尾时失败，gz.Close 可能才会返回错误。因此发布下载链接前不要只看 Write 是否成功，也不要忽略 Close 的返回值。

读取端怎样确认文件真的完整

gzip.NewReader 成功只说明头部可识别，不能证明整个文件没有被截断。读取端需要把数据读到 io.EOF；Go 文档说明，Reader 在读到未压缩数据末尾时才会检查预期长度和 checksum，错误可能在最后一次 Read 才出现。

func readGZIP(path string) ([]byte, error) {
    // 打开文件后由 defer 负责释放底层句柄。
    file, err := os.Open(path)
    if err != nil {
        return nil, err
    }
    defer file.Close()

    gz, err := gzip.NewReader(file)
    if err != nil {
        return nil, err
    }
    // Reader.Close 不关闭 file；两层资源要分别释放。
    defer gz.Close()

    // ReadAll 会持续读取到 EOF，因而能暴露尾部缺失或 checksum 错误。
    data, err := io.ReadAll(gz)
    if err != nil {
        return nil, err
    }
    return data, nil
}

上例还需要在导入区加入 io。若业务不想一次性加载全文，可使用循环 Read；判断标准仍然是读到 io.EOF 后才认为内容完整。Reader 的 Close 不会关闭底层文件，不能用它替代 file.Close。

按现象排查 Go gzip 无法解压

排查时可以先比较生成前后的文件大小，再用 Go 读取端做一次完整消费；不要因为压缩文件存在或 NewReader 没报错，就把半成品标记为成功。若生产代码通过 HTTP 输出压缩流，响应结束前同样要处理 Writer.Close 返回的错误。

常见问题

只调用 gzip.Writer.Flush 能不能生成可解压文件？

不应把它当作文件收尾方案。Flush 会把当前可刷新的压缩数据写出，但 GZIP footer 由 Close 写入；文件落盘前应调用 Close。

gzip.Writer.Close 会自动关闭 os.File 吗？

不会。它只关闭 gzip 层并写入底层 Writer，底层文件仍由调用方关闭。

为什么 gzip.NewReader 成功，后面仍然 checksum error？

NewReader 主要解析头部；完整性校验要在读取到数据末尾时完成。请继续读取至 io.EOF，并检查最后一次读取返回的错误。