Go 生成的 ZIP 无法打开怎么检查 Writer 关闭顺序

Go 生成的 ZIP 无法打开时，最先检查的不是压缩级别，而是收尾顺序：先把当前条目写完，调用并检查 zip.Writer.Close()，最后再关闭文件或把缓冲区交给下游。Writer.Close 负责把 ZIP 的 central directory 写入底层 writer，但它不会替你关闭底层 writer；如果少了这一步，文件看起来有内容，却可能缺少归档目录。

Go ZIP 文件为什么在 Writer.Close 前并不完整

一个 ZIP 不只有文件内容。Writer.Create 返回的 writer 负责写入当前条目，归档末尾还需要 central directory 记录每个条目的名称、偏移和大小。官方文档明确说明，Writer.Close 会写入这个目录，而不会关闭底层 io.Writer。因此，只执行 f.Close() 或只把当前内容写完，都不能替代 zw.Close()。

另一个容易忽略的边界是：当前条目的内容必须在下一次 Create、CreateHeader 或 Close 前写完。不要把一个条目的 writer 保存起来，切换到下一个条目后再回头补写。遇到压缩器或底层 writer 报错时，错误也可能延迟到 zw.Close() 才暴露，所以不能写成只调用不判断返回值的空收尾。

func writeZip(path string) (err error) {
	// 文件是最终输出目标，zip.Writer 不会替它执行 Close。
	f, err := os.Create(path)
	if err != nil {
		return err
	}
	defer func() {
		// 只有前面没有错误时，才把底层 Close 的错误作为结果返回。
		if closeErr := f.Close(); err == nil {
			err = closeErr
		}
	}()

	zw := zip.NewWriter(f)
	entry, err := zw.Create("hello.txt")
	if err != nil {
		return err
	}
	if _, err = io.WriteString(entry, "hello from Go\n"); err != nil {
		return err
	}
	// 先完成 ZIP 的 central directory，再由 defer 关闭底层文件。
	return zw.Close()
}

这段代码的关键不是 defer 本身，而是两个对象的生命周期分开：zw.Close() 先发生，f.Close() 后发生。若要把底层关闭错误与 ZIP 收尾错误都记录得更细，可以把两个错误分别写入日志，但不要忽略 zw.Close() 的返回值。

怎么把关闭顺序固定成可检查的写入链

如果输出目标是内存缓冲区，可以在返回字节前先关闭 ZIP writer；如果输出目标是 HTTP 响应，也应在 handler 返回前完成 zw.Close()，再让响应写出。Flush 不是通常的补救动作，官方说明是调用 Close 已经足够。

func buildZip() ([]byte, error) {
	// 先在内存中组装，便于把 ZIP 完整字节交给上传或响应层。
	buf := new(bytes.Buffer)
	zw := zip.NewWriter(buf)

	entry, err := zw.Create("report.txt")
	if err != nil {
		return nil, err
	}
	if _, err = io.WriteString(entry, "daily report\n"); err != nil {
		return nil, err
	}
	if err = zw.Close(); err != nil {
		// Close 失败时，buf.Bytes() 不能当作完整 ZIP 使用。
		return nil, err
	}
	return append([]byte(nil), buf.Bytes()...), nil
}

文件、对象存储上传器和 HTTP 响应都可以套用同一条规则：条目 Write 成功 → zip.Writer.Close 成功 → 下游发送或关闭成功。不要在 zw.Close() 之前读取缓冲区并上传，也不要在关闭底层文件后再尝试让 ZIP writer 写 central directory。

写入成功后，如何区分关闭顺序和其他损坏原因

先用 zip.NewReader 或 zip.OpenReader 做一次最小读取。能打开目录，说明 central directory 大概率已经存在；此时再打开具体条目并读取，才能发现内容截断或 CRC 校验问题。若连 reader 都返回 zip: not a valid zip file，应优先回到输出长度、zw.Close() 返回值和底层 writer 是否提前关闭这三项。

func checkZip(data []byte) error {
	// NewReader 需要完整字节和长度，适合检查交付前的内存结果。
	r, err := zip.NewReader(bytes.NewReader(data), int64(len(data)))
	if err != nil {
		return fmt.Errorf("open zip: %w", err)
	}
	for _, file := range r.File {
		// Open 会在读取条目时暴露解压或校验错误。
		reader, err := file.Open()
		if err != nil {
			return fmt.Errorf("open %s: %w", file.Name, err)
		}
		_, readErr := io.Copy(io.Discard, reader)
		closeErr := reader.Close()
		if readErr != nil {
			return fmt.Errorf("read %s: %w", file.Name, readErr)
		}
		if closeErr != nil {
			return fmt.Errorf("close %s: %w", file.Name, closeErr)
		}
	}
	return nil
}

这里的检查不是为了证明每个业务文件都正确，而是为了快速分层。目录打不开，查收尾和截断；目录能打开但条目读取失败，查内容写入、压缩或传输；读取成功但业务仍认为文件不对，再查文件名、编码、业务内容和上传后的二次处理。

Go 生成 ZIP 的关闭顺序检查清单

• 每次 Create 返回后，先完成这个 entry 的全部写入，再创建下一个 entry。
• 调用 zw.Close() 并处理错误；不要把它当成可省略的 Flush。
• 确认底层 os.File、缓冲区、上传器或响应对象没有在 ZIP 收尾前关闭或截断。
• 交付前记录字节长度；必要时用 zip.NewReader 打开目录并读取每个条目。
• 文件名使用相对路径和正斜杠，避免把路径格式问题误判成关闭顺序问题。

相关问题

调用 Writer.Flush 后还需要 Writer.Close 吗？

需要。Flush 只处理缓冲数据，Close 才负责完成 ZIP 的 central directory；通常直接正确调用 Close 即可。

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

不会。zip.Writer 只使用底层 writer，文件或网络响应的关闭仍由调用方负责，而且应放在 ZIP writer 收尾之后。

为什么 ZIP 能列出文件但解压仍报错？

这通常说明目录已经写出，问题转移到了条目内容、压缩数据或传输后的字节变化；继续读取每个条目并检查 CRC，而不是只重复调用 Close。

参考：Go archive/zip 官方文档。