gzip.Reader必须配合io.Copy或显式处理io.EOF，因它不自动在末尾返回io.EOF，直接循环Read易卡死或漏数据；最简可靠做法是用io.Copy，其内部已完整处理边界逻辑。
gzip.Reader 必须配合 io.Copy 或显式处理 io.EOF
直接循环调用 gzip.Reader.Read 极易卡死或漏数据，因为 gzip.Reader 不会在流末尾自动返回 io.EOF —— 它可能最后一次返回 n > 0, err == nil，下一次才返回 io.EOF。若只检查 err == io.EOF 就退出，会丢掉最后一块解压数据；若不检查，循环永远不终止。
最简可靠做法是交给 io.Copy：它内部已完整处理边界逻辑，包括多次读取、io.EOF 判定和错误传播。
- 需要流式转发（如 HTTP 响应）：直接
io.Copy(dstWriter, gzipReader) - 需要逐块处理（如日志行解析、限速）：每次
Read(p []byte)后同时检查n和err，满足n == 0 && err == io.EOF或err == io.EOF才停止 - 别依赖
gzip.Reader.Close()判断流是否结束——它只释放 zlib 内存，不反映数据是否读完
zlib 流式解析 uint64 等二进制字段必须用 io.ReadFull
原始 zlib.Reader 的 Read([]byte) 返回长度不可控，可能把一个 uint64 拆成两次读（比如先读 3 字节，再读 5 字节），导致解析器必须维护状态机，极易出错。
正确做法是套一层 bufio.Reader，再用 io.ReadFull 强制读满指定字节数：
立即学习“go语言免费学习笔记（深入）”；
-
bufio.NewReaderSize(zlibReader, 64*1024)推荐缓冲区大小，兼顾缓存命中与内存占用 - 解析固定长度字段（如
uint32、uint64、自定义 header）一律用io.ReadFull(br, buf[:])，不是br.Read(buf[:]) -
io.ReadFull会自动重试，直到填满或返回真实错误（io.EOF、io.ErrUnexpectedEOF等），彻底规避跨 chunk 拆分
tar.gz 解压必须嵌套 Reader，且 tar.Header.Size 是关键约束
tar.gz 是两层封装：gzip.Reader 解压后输出的是原始 tar 流，不能直接丢给 tar.Reader —— 必须用 tar.NewReader(gzipReader) 显式嵌套。
更关键的是：每个 tar.Header 的 Size 字段指明了对应文件内容的精确字节数。若用 io.Copy 直接复制整个 tar.Reader，会把下一个文件头也一起读进来，造成后续解析错位。
- 正确流程：读
tar.Header→ 检查Header.Typeflag（区分文件/目录）→ 调用io.CopyN(dst, tr, header.Size)精确读取内容 - 不要用
io.Copy(dst, tr)处理单个文件体，否则破坏 tar 流结构 - 路径需做安全校验（如拒绝
../），os.MkdirAll创建父目录，os.Chmod恢复权限
大文件流式处理必须避免 ioutil.ReadAll 和 bytes.Buffer
用 ioutil.ReadAll 或 bytes.Buffer 全量读取解压结果，等于放弃流式优势：内存占用随文件体积线性增长，GC 压力陡增，延迟不可控。
所有场景都应坚持“边解压、边消费”原则：
- 写入磁盘：用
os.Create+io.Copy - 网络响应：直接
io.Copy(httpResponseWriter, gzipReader) - 结构化解析：通过
bufio.Reader+io.ReadFull按协议边界读取（如消息头+body） - 压缩级别可调：创建
gzip.NewWriterLevel时传入gzip.BestSpeed或gzip.BestCompression，但注意高压缩率会增加 CPU 开销
真正难的不是调用哪个函数，而是每层 Reader 的生命周期、缓冲区边界、以及错误发生时数据消费到了哪一步——这些细节在高吞吐或长连接场景下会立刻暴露。
