Go gzip 写入结束后怎么正确关闭并刷新尾部

用 compress/gzip 压缩数据时，Write 返回成功并不代表完整 GZIP 文件已经写完。压缩器可能还保留着缓冲数据，文件格式需要的 footer 也要等 Close 才写入。正确的收尾通常是：普通文件和内存输出直接调用 Close；只有需要让网络对端尽快拿到一段可解码数据时，才在中途调用 Flush，结束时仍然必须调用 Close。

先分清 Flush 和 Close 各自解决什么

gzip.Writer 底层包含 DEFLATE 压缩器和 GZIP 封装。Write 只承诺接收输入，压缩后的字节不一定立刻写入目标；Flush 会把当前待写压缩数据送出，适合压缩网络协议需要分段传输的场景。它相当于同步刷新，并没有结束整个 GZIP 成员。

Close 才是“写入结束”的动作：它先处理剩余数据，再写 GZIP footer，其中包含未压缩数据的长度和校验信息。少了这一步，bytes.Buffer 里可能看似有内容，读取端却在末尾遇到校验错误或不完整 EOF。下面的关系图把业务数据、压缩器、底层 Writer 和尾部的职责放在一起：

文件、内存和网络场景的关闭写法

写本地文件时，先关闭 gzip.Writer，再关闭文件。因为 gzip.Writer.Close 只操作它收到的 io.Writer，不会关闭 *os.File。同时要把两个 Close 的错误都纳入返回值，不能只依赖一个无名的 defer：

import (
	"compress/gzip"
	"os"
)

func writeGZIP(path string, data []byte) (err error) {
	// 文件是 gzip.Writer 的底层输出目标。
	f, err := os.Create(path)
	if err != nil {
		return err
	}
	defer func() {
		// gzip.Writer 已经收尾后，再释放文件描述符，并保留关闭错误。
		if closeErr := f.Close(); err == nil && closeErr != nil {
			err = closeErr
		}
	}()

	zw := gzip.NewWriter(f)
	if _, err = zw.Write(data); err != nil {
		// 写入失败时也尝试结束压缩器，避免遗漏底层错误。
		_ = zw.Close()
		return err
	}
	// Close 会刷新剩余数据并写入 GZIP footer。
	return zw.Close()
}

如果目标是 bytes.Buffer，底层对象没有需要释放的资源，但 zw.Close() 仍不可省略。网络场景中可以对每个逻辑片段调用一次 Flush，让接收端及时获得可处理的数据；所有输入结束后再调用 Close，然后再按连接或响应对象的规则结束底层流。

一个容易混淆的点是关闭层级：gzip.Writer 负责压缩格式，os.File、net.Conn 或 HTTP body 负责外层资源。图2展示了这些对象之间的静态依赖和错误返回路径：

从读取端确认尾部是否完整

不要只看压缩字节数变大就判断成功。可以让读取端完整消费到 io.EOF；gzip.Reader 会在读到压缩数据末尾时校验 GZIP 中的长度和 checksum，读取中途停止无法证明尾部正确。

func checkGZIP(data []byte) error {
	// 用内存中的压缩内容构造读取器，模拟下游消费。
	zr, err := gzip.NewReader(bytes.NewReader(data))
	if err != nil {
		return err
	}
	defer zr.Close()

	// 读到 EOF，才能触发完整的尾部校验。
	_, err = io.Copy(io.Discard, zr)
	return err
}

这里的检查只用于说明判断方式：正式写文件时，优先在写入阶段处理 Write 和 Close 的错误；测试中再用读取端覆盖“尾部没有写完”的回归场景。

常见关闭误区与检查清单

只调用 Flush，不调用 Close，可以吗？

不可以。Flush 适合中途发送压缩块，不等于写入 GZIP footer。结束时必须 Close。

把 gzip.Writer.Close 放进 defer 就足够了吗？

简单示例可以这样写，但生产代码容易丢掉 Close 返回的 I/O 错误。需要可靠落盘或上传时，应显式关闭并处理错误。

调用 gzip.Writer.Close 后文件会自动关闭吗？

不会。关闭 gzip.Writer、关闭底层文件或连接分别由不同对象负责，顺序通常是先 gzip、后底层资源。

官方文档明确说明，Write 的压缩字节可能直到关闭才刷新；Close 会写入 GZIP footer，Flush 则用于把待写压缩数据推到底层 Writer。围绕这三条边界组织代码，基本就能避免“文件能打开但尾部不完整”的问题。

参考资料：compress/gzip 官方包文档、Go 官方 gzip 源码。