Go archive/zip 怎么读取条目的原始压缩数据而不是解压内容

处理归档重打包、压缩格式识别或增量传输时，你可能需要 ZIP 条目在归档中保存的那段原始字节，而不是解压后的文件内容。Go 的 archive/zip 已经把这个选择拆成两个接口：File.Open() 返回解压内容，File.OpenRaw() 返回不经过解压的原始压缩数据。

核心结论：需要业务文件内容时用 Open；需要保留 ZIP 内部压缩层、读取 CompressedSize64 对应的字节或交给别的解析器时用 OpenRaw。OpenRaw 返回的是普通 io.Reader，不负责条目关闭，但通过 OpenReader 打开的归档仍然必须关闭。

官方参考地址：https://pkg.go.dev/archive/zip#File.OpenRaw

先分清 Open 和 OpenRaw 返回的数据

zip.File 同时携带文件名、压缩方法、压缩后大小和解压后大小等元数据。真正读取条目时，调用方的目标决定接口：Open 负责把压缩层转换成文件内容；OpenRaw 只定位条目的数据区，按 CompressedSize64 读取原始字节。

图1：数据层级说明图，区分 File.Open 的解压内容与 File.OpenRaw 的原始压缩字节。

因此，OpenRaw 并不是“更快的 Open”，也不是把文件内容换一种类型返回。对于 Store 方法，原始字节通常与解压内容相同；对于 Deflate 等压缩方法，两者的长度和内容都可能不同。

用 OpenRaw 导出原始压缩数据

下面的场景是把归档中的 assets/data.bin 原样导出为一个压缩层文件。导出的文件不是业务上可直接使用的解压文件，它保留的是 ZIP 条目数据区，适合后续由已知压缩格式的组件继续处理。

package main

import (
	"archive/zip"
	"fmt"
	"io"
	"os"
)

func exportRaw(zipPath, entryName, dstPath string) error {
	archive, err := zip.OpenReader(zipPath)
	if err != nil {
		return fmt.Errorf("打开 ZIP 失败: %w", err)
	}
	defer archive.Close() // 归档持有底层文件句柄，函数退出时统一关闭

	for _, entry := range archive.File {
		if entry.Name != entryName {
			continue // 只导出指定条目，避免误处理同名相近的路径
		}
		if entry.FileInfo().IsDir() {
			return fmt.Errorf("条目是目录: %s", entry.Name)
		}

		raw, err := entry.OpenRaw()
		if err != nil {
			return fmt.Errorf("定位原始数据失败: %w", err)
		}

		out, err := os.Create(dstPath)
		if err != nil {
			return fmt.Errorf("创建导出文件失败: %w", err)
		}
		_, copyErr := io.Copy(out, raw) // raw 只读压缩数据区，不会执行解压
		closeErr := out.Close()         // 即使复制失败，也要释放导出文件
		if copyErr != nil {
			return fmt.Errorf("导出原始数据失败: %w", copyErr)
		}
		if closeErr != nil {
			return fmt.Errorf("关闭导出文件失败: %w", closeErr)
		}
		return nil
	}

	return fmt.Errorf("找不到条目: %s", entryName)
}

这段代码里最容易遗漏的是资源层级：raw 没有 Close，因为它只是一个有边界的读取器；真正打开了磁盘归档的是 zip.OpenReader，所以由 archive.Close() 负责关闭。目标文件则必须单独处理创建和关闭错误。

处理错误与资源边界

OpenRaw 的实现会先定位本地文件头，再返回一个限定长度的读取器。它不需要知道压缩方法对应的解压器，因此条目的压缩方法未知时，仍然可以读取原始字节；这不代表这些字节已经是可用的业务内容。

相对地，Open 会根据压缩方法选择解压器，并用校验读取器在读到末尾时核对解压后的长度和 CRC。压缩算法没有对应解压器时，Open 会返回 zip.ErrAlgorithm；压缩内容损坏时，错误可能在后续读取过程中出现，所以不能只判断打开动作成功。

图2：资源与错误边界说明图，查看归档关闭责任以及 Open 的校验路径。

func readContent(entry *zip.File) ([]byte, error) {
	rc, err := entry.Open()
	if err != nil {
		return nil, fmt.Errorf("打开解压内容失败: %w", err)
	}
	defer rc.Close() // Open 返回 ReadCloser，读取完成后必须关闭

	data, err := io.ReadAll(rc)
	if err != nil {
		return nil, fmt.Errorf("读取或校验解压内容失败: %w", err)
	}
	return data, nil
}

如果调用方只想保留压缩层，不要为了“统一接口”先调用 Open 再重新压缩：这样会丢失原始压缩参数，也可能改变字节结果。反过来，拿到 OpenRaw 的结果后也不能直接把它当成普通文件内容解析。

按后续用途做 API 设计决策

可以先看条目的几个字段，再决定把哪一层交给下游：

• Method 表示压缩方法；zip.Store 表示不压缩，zip.Deflate 是常见的 DEFLATE。
• CompressedSize64 是归档中数据区的长度，适合估算 OpenRaw 的读取边界。
• UncompressedSize64 是解压后内容的长度，适合判断业务文件大小和内存风险。
• 需要 CRC 和解压完整性时选 Open；需要转存、二次解析或保留原始压缩层时选 OpenRaw。

func describe(entry *zip.File) string {
	return fmt.Sprintf(
		"name=%s method=%d compressed=%d uncompressed=%d",
		entry.Name,
		entry.Method,
		entry.CompressedSize64,   // 归档中保存的压缩字节数
		entry.UncompressedSize64, // 解压后业务内容的字节数
	)
}

最终可以把决策压缩成一句话：Open 面向“我要文件内容”，OpenRaw 面向“我要 ZIP 保存的那一层字节”。只要先写清楚下游需要哪一种数据，关闭责任和错误处理就不会混在一起。

常见问题

OpenRaw 返回值为什么不能直接 Close？

因为它返回的是 io.Reader，实现本身只是一个限定范围的读取器；归档底层资源由 zip.ReadCloser 持有，关闭归档即可。

OpenRaw 读取到的内容能直接当作原文件吗？

只有条目使用 zip.Store 时才通常与原内容一致。使用 Deflate 等方法时，必须根据 Method 交给相应的解压逻辑，或者改用 Open 获取经过标准库处理的内容。

参考源码：https://go.dev/src/archive/zip/reader.go