Go compress/gzip 正确关闭 Writer 写入尾部

Go 的 compress/gzip 写入器不能只调用 Write 就结束。压缩数据可能仍停留在 gzip.Writer 或其内部压缩器中，必须调用 Close，它才会把未写出的数据刷新到下层，并写入 GZIP 尾部。这里的 Close 只关闭压缩写入器，不会替你关闭文件、缓冲区或网络连接。

官方地址：https://pkg.go.dev/compress/gzip

最稳妥的顺序是：先创建底层输出，再创建 gzip.Writer，写入并检查错误，最后关闭 gzip.Writer；如果底层资源也需要关闭，让它在压缩器之后关闭。

先看清两个 Writer 的责任边界

gzip.NewWriter(w) 接收一个实现了 io.Writer 的下层对象。上层的 gzip.Writer 负责压缩格式和 GZIP 尾部，下层对象负责真正保存或发送字节。官方文档明确说明，Write 产生的压缩字节不一定会立即写入下层；Close 会刷新未写数据并写入尾部，但不会关闭下层 io.Writer。

因此，下面的关闭顺序是有意义的：先让 gzip 写入器完成收尾，再关闭文件等底层资源。如果反过来关闭文件，gzip.Writer.Close 可能无法把最后的尾部写出去。

写文件时怎样正确收尾

一次性生成 gzip 文件时，可以把底层文件和压缩写入器分别注册到 defer。由于 defer 后进先出，先注册文件、后注册 gzip，执行时就会先关闭 gzip，再关闭文件：

package main

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

func writeGZIP(path string, data []byte) (err error) {
    // 文件负责保存最终的 gzip 字节，先注册它的兜底关闭。
    file, err := os.Create(path)
    if err != nil {
        return fmt.Errorf("create gzip file: %w", err)
    }
    defer func() {
        // 文件关闭错误不能覆盖前面更重要的写入或 gzip 收尾错误。
        if closeErr := file.Close(); err == nil && closeErr != nil {
            err = fmt.Errorf("close file: %w", closeErr)
        }
    }()

    gz := gzip.NewWriter(file)
    // 后注册的 defer 先执行，保证 gzip 尾部先写进文件。
    defer func() {
        if closeErr := gz.Close(); err == nil && closeErr != nil {
            err = fmt.Errorf("close gzip writer: %w", closeErr)
        }
    }()

    // Write 只负责提交压缩输入，错误仍要立即返回给调用方。
    if _, err = gz.Write(data); err != nil {
        return fmt.Errorf("write gzip data: %w", err)
    }
    return nil
}

这个写法把 Close 的错误纳入返回值，而不是用 defer gz.Close() 静默丢弃。对普通本地文件，文件关闭错误也可能反映出落盘阶段的问题，所以示例保留了两层错误处理。

为什么只检查 Write 仍然不够

Write 成功，只能说明输入已经交给 gzip 写入器处理；最后的压缩器收尾、GZIP 校验信息和尾部写入仍发生在 Close 阶段。若下层是网络响应、限流 Writer 或会返回错误的自定义 Writer，Close 也必须检查。

func writeTo(dst io.Writer, data []byte) (err error) {
    gz := gzip.NewWriter(dst)
    // 兜底路径也要检查 Close，避免 footer 写入错误被吞掉。
    defer func() {
        if closeErr := gz.Close(); err == nil && closeErr != nil {
            err = fmt.Errorf("finish gzip stream: %w", closeErr)
        }
    }()

    // 这里的错误表示压缩输入或下层写入已经出现问题。
    if _, err = gz.Write(data); err != nil {
        return fmt.Errorf("write compressed data: %w", err)
    }
    return nil
}

如果函数同时有多个可能返回点，建议使用命名返回值，让延迟关闭函数只在前面没有错误时补充 Close 错误。已经有错误时，不要为了“同时返回两个错误”而覆盖最早的根因；需要聚合多个错误时，再显式使用项目约定的错误组合方式。

Flush、Close 和 Reset 分别什么时候用

• Close 用于一个 gzip 流的最终收尾，必须在完成写入后调用。
• Flush 用于压缩网络协议等需要尽快把暂存数据推给接收端的场景，它不等于最终关闭，也不替代最后的 Close。
• Reset 用于复用同一个 gzip.Writer 写向新的下层目标；复用前仍要先结束上一段流，且新的目标要承担自己的关闭责任。

如果只是写一个完整文件，通常不需要主动调用 Flush。对 HTTP 流式输出，是否提前刷新要结合响应协议和延迟目标判断；刷新会增加写出次数，不能把它当成“保证数据已经永久保存”的同步落盘操作。

常见问题

只关闭文件，不关闭 gzip.Writer，会怎样？

文件可能已经存在，但最后一段压缩数据和 GZIP 尾部未完整写入，读取端就可能遇到截断或校验失败。应先关闭 gzip，再关闭文件。

gzip.Writer.Close 会关闭底层文件吗？

不会。它只完成压缩写入器自身的收尾，底层文件、缓冲区或连接由创建它们的代码负责关闭。

defer gzipWriter.Close() 能不能用？

可以作为兜底，但如果 Close 返回错误而代码不读取它，尾部写入失败就会被静默忽略。生产代码至少应把关闭错误写入命名返回值或明确记录。

小结

记住三点即可：Write 提交压缩输入，Close 完成刷新和 GZIP 尾部，底层 io.Writer 仍由调用方关闭。把这三个责任分开，文件压缩、HTTP 输出和 Writer 复用都更容易写出可维护的收尾逻辑。