Go gzip Writer Close 为什么必须调用

调用 gzip.NewWriter 后，写入的数据只是交给压缩器处理，并不代表一个完整的 gzip 数据流已经落到底层 writer。gzip.Writer.Close 必须调用，因为它会结束压缩状态、写出 gzip 尾部信息，并把关闭阶段的错误返回给调用方。省略它时，生成的文件或响应可能看起来有内容，却在读取末尾时报错或无法被完整解压。

为什么 Close 不能省略

gzip 数据不是“把若干压缩块写完”就结束了。压缩器还需要在流尾写入用于完整性判断的 CRC32 和原始数据长度等尾部字段。gzip.Writer 持有这些状态，只有在 Close 时才知道压缩流已经结束，才能把尾部写到它包装的 io.Writer。

因此，省略 Close 常见的表现有三种：输出文件比预期短、读取端在末尾得到 unexpected EOF，或者某些读取器暂时读出正文却在校验阶段失败。问题不一定出现在 Write，而可能发生在最后一个尾部写入动作。

正确的关闭顺序怎么写

写文件时，可以让函数返回命名错误值，并把两个关闭动作放进逆序执行的 defer。先注册底层文件的关闭，再注册 gzip writer 的关闭，运行时就会先完成 gzip 尾部，再关闭文件。这样既不会提前截断输出，也不会把关闭错误丢掉。

package main

import (
    "compress/gzip"
    "os"
)

func writeGZIP(path string, data []byte) (err error) {
    // 先打开最终输出文件；底层文件的关闭 defer 要最后执行。
    file, err := os.Create(path)
    if err != nil {
        return err
    }
    defer func() {
        // 只有前面没有错误时，才把文件关闭错误作为返回值。
        if closeErr := file.Close(); err == nil {
            err = closeErr
        }
    }()

    writer := gzip.NewWriter(file)
    defer func() {
        // defer 按后进先出执行，保证 gzip 尾部先写入文件。
        if closeErr := writer.Close(); err == nil {
            err = closeErr
        }
    }()

    // Write 的错误和 Close 的错误都需要交给调用方判断。
    _, err = writer.Write(data)
    return err
}

这里的关键不是把 Close 写成一行形式，而是保留它的返回值。若函数已经因为 Write 失败，示例优先保留原始写入错误；如果写入本身成功，则把 Close 或底层文件关闭错误返回出去。

Flush、Close 和底层 Writer 有什么区别

Flush 解决的是“当前已经产生的压缩数据要尽快交给下游”，常见于长连接或分段输出；它并不表示 gzip 流已经完成。最终写文件、结束 HTTP 响应或准备让读取端看到完整校验信息时，仍然要调用 Close。

gzip.Writer.Close 也不会替你关闭底层的 io.Writer。例如底层是文件、网络连接或另一个带有关闭语义的 writer，仍应由创建它的那一层负责关闭。可以把职责记成：gzip writer 完成压缩格式，底层 writer 完成外部资源。

常见误区与排查现象

如果底层是网络响应，除了调用 Close，还要根据协议和框架的生命周期处理响应提交；不要把“gzip writer 已关闭”误认为“客户端一定已经成功收到全部数据”。

常见问题

Close 会不会重复关闭底层文件？

不会。gzip.Writer.Close 负责完成 gzip writer 本身，不负责关闭它包装的底层 io.Writer。底层资源仍由拥有它的代码关闭。

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

不应依赖它。Flush 的重点是推进尚未输出的数据，最终文件仍需要 Close 写出完整尾部。

为什么要检查 Close 的错误？

尾部和最后一段压缩数据都是在关闭阶段写出的，底层磁盘、管道或网络写入可能在此时失败。忽略 Close 错误，就可能把不完整的 gzip 文件当成成功结果。