Go compress/zlib.NewReader 怎样读取压缩数据流

处理压缩响应、缓存文件或消息体时，常见输入并不是一个可以直接读取的文本流，而是一段 zlib 封装的数据。Go 标准库的 compress/zlib.NewReader 会把它转换成 io.ReadCloser，后续可以交给 io.Copy，也可以逐块读取。关键是先确认格式，再处理创建错误、读取错误和关闭边界。

官方资料地址：https://pkg.go.dev/compress/zlib#NewReader

如果输入确实是 zlib 流，最小路径就是 zlib.NewReader(input)、消费返回的读取器、最后 Close。不要把 gzip 文件直接交给它，也不要只检查创建阶段而忽略后续读取错误。

下面的示例围绕一个具体任务展开：从任意 io.Reader 读取 zlib 数据，并把解压后的内容写到另一个 io.Writer。

先确认输入属于 zlib 格式

compress/zlib 实现的是 zlib 格式，也就是 RFC 1950 的封装；它和常见的 gzip 文件不是同一个容器。两者都可能包住 deflate 数据，但头部、校验和与读取 API 不同。若上游给的是 .gz 文件，应使用 compress/gzip，不要因为“都是压缩数据”就混用。

文章的核心关系可以先看成三层：输入端提供压缩字节，NewReader 负责建立解压读取器，业务端只消费解压后的字节。

用 NewReader 创建流式解压器

NewReader 的参数是 io.Reader，返回值是 io.ReadCloser 和错误。创建阶段可能因为输入头部不符合 zlib 格式而失败，所以不要把错误留到后面的 io.Copy 才处理。返回成功后，应立即安排关闭动作。

package main

import (
	"compress/zlib"
	"fmt"
	"io"
)

// decompressZlib 把 zlib 输入流解压到目标 Writer。
func decompressZlib(dst io.Writer, src io.Reader) error {
	reader, err := zlib.NewReader(src)
	if err != nil {
		// 头部或格式不正确时，读取器并未建立成功。
		return fmt.Errorf("创建 zlib 读取器: %w", err)
	}
	defer func() {
		// Close 负责释放解压器持有的内部资源；错误在函数末尾统一处理。
		_ = reader.Close()
	}()

	if _, err := io.Copy(dst, reader); err != nil {
		// Copy 的错误可能来自输入流、解压过程或目标 Writer。
		return fmt.Errorf("读取并解压 zlib 数据: %w", err)
	}
	return nil
}

这个版本把读取过程保持为流式：压缩输入不必先整体读入内存，解压结果也会随着 io.Copy 被写出。对于网络响应、文件或管道，只要它们实现了 io.Reader，调用方式都一样。

读取阶段还要保留错误处理

创建读取器成功，只能说明 zlib 读取器已经建立，不代表后续数据一定完整。压缩流可能在中途被截断，校验和也可能在读取尾部时才暴露。因此实际代码不能只写 zlib.NewReader 后就把返回值交给下游。

func readZlibText(src io.Reader) ([]byte, error) {
	reader, err := zlib.NewReader(src)
	if err != nil {
		return nil, fmt.Errorf("zlib 头部无效: %w", err)
	}

	data, readErr := io.ReadAll(reader)
	closeErr := reader.Close()
	if readErr != nil {
		// 读取中途失败时优先保留解压或输入错误。
		return nil, fmt.Errorf("读取解压内容: %w", readErr)
	}
	if closeErr != nil {
		// 关闭阶段错误也要保留，尤其是封装流尚未完整消费时。
		return nil, fmt.Errorf("关闭 zlib 读取器: %w", closeErr)
	}
	return data, nil
}

io.ReadAll 适合结果本身就不大、需要一次性返回的场景；大文件或大响应则应优先使用 io.Copy 或固定大小的缓冲区，避免把解压后的全部内容同时放进内存。

不要把 zlib、gzip 和裸 deflate 混在一起

格式选择要跟上游协议保持一致。zlib 有自己的头部和校验信息，gzip 也有独立的文件封装，裸 deflate 则连 zlib 的封装都没有。错误通常表现为创建读取器时的头部错误，但更可靠的做法是在接口或文件格式定义处就明确记录压缩类型。

如果压缩数据依赖预置字典，不能继续调用普通的 NewReader 期待它自动猜出字典，而应让发送端和接收端约定同一份字典，再使用 NewReaderDict。字典不匹配时，官方 API 会返回 ErrDictionary。

把 Close 和资源所有权放在正确位置

返回的对象是 io.ReadCloser，关闭责任属于创建它的调用方。若把读取器继续传给下层函数，可以在所有权交接处写清楚“由谁关闭”；若当前函数创建并消费它，就在当前函数内安排 defer 或显式关闭。

• 创建失败：没有可关闭的读取器，直接返回格式或输入错误。
• 读取失败：保留 io.Copy、io.ReadAll 或自定义循环返回的错误。
• 读取成功：仍然完成 Close，不要把关闭当作可选清理。
• 字典场景：只有协议明确使用预置字典时才切换到 NewReaderDict。

实际采用时的最小决策

如果你只需要把 zlib 响应解压到文件或另一个流，选择 NewReader + io.Copy；如果函数需要返回一个小的内存结果，再选择 NewReader + io.ReadAll。遇到创建阶段错误，先核对上游格式；遇到读取尾部错误，再检查数据是否截断或校验失败；只有在协议明确给出字典时，才引入 NewReaderDict。

这样写的好处是每个边界都对应一个具体动作：格式由包选择表达，流式处理由 Reader/Writer 连接表达，生命周期由 Close 表达，错误则在创建、读取和关闭三个阶段分别保留。它比把压缩数据一次性读入内存后再猜格式更容易维护。

相关问题

zlib.NewReader 能直接读取 gzip 文件吗？

不能。gzip 使用独立的文件封装，应使用 compress/gzip 的读取器；zlib 与 gzip 只是都可能使用 deflate，并不意味着 API 可以互换。

为什么 NewReader 成功后仍可能在 Copy 阶段报错？

创建阶段主要建立读取器并检查头部，压缩流的主体、尾部和校验信息要在持续读取时才会被消费，因此截断或校验错误可能延后出现。

什么时候应该使用 NewReaderDict？

只有压缩端明确使用了预置字典，并且解压端能取得同一份字典时才使用。普通 zlib 流不需要额外字典，错误引入字典反而会增加协议复杂度。