Go flate.NewReader 读取压缩流时怎样处理短读

如果把 flate.NewReader 当成“每次都填满缓冲区”的读取器，短读就很容易被误判成结束。正确的判断标准不是 n ，而是先消费本次已经返回的 n 个字节，再根据 err 判断是否结束。完整 DEFLATE 流在最终块之后才返回 io.EOF；底层输入被截断时，通常应按结构未完成来处理，而不是把它当成正常 EOF。

处理 flate.Reader 时牢记两条：短读只说明这次拿到的字节少于缓冲区容量，不能说明流结束；当 n > 0 与错误同时出现时，先处理这批数据，再处理错误。

先把“短读”和“读完”分开

io.Reader 的约定是“最多读取 len(p) 个字节”，而不是保证填满 p。网络流、管道、分段读取器，甚至人为限制每次读取大小的包装器，都可能返回小于缓冲区容量的 n。因此下面这种判断是有问题的：

// 错误示例：短读不代表解压流已经结束。
n, err := zr.Read(buf)
if n 

更稳妥的循环要把两个返回值拆开看：n 表示本次已经交付的数据，err 表示本次或下一次读取的状态。即使同一次返回同时带有数据和错误，也不能跳过这批数据。

用可控底层 Reader 复现短读

下面的包装器只限制底层每次最多读几个字节，用来模拟流式输入。它没有改变 DEFLATE 数据，只改变了输入到解压器的分段方式。

package main

import (
    "bytes"
    "compress/flate"
    "fmt"
    "io"
)

// chunkReader 把底层输入切成小块，模拟网络或管道的短读。
type chunkReader struct {
    r   io.Reader
    max int
}

func (c *chunkReader) Read(p []byte) (int, error) {
    if len(p) > c.max {
        p = p[:c.max]
    }
    return c.r.Read(p)
}

func main() {
    source := []byte("一段会被分块送入 flate.Reader 的文本")
    var compressed bytes.Buffer

    zw, err := flate.NewWriter(&compressed, flate.DefaultCompression)
    if err != nil {
        panic(err)
    }
    // Close 会写出压缩流的结束信息，不能只调用 Write 就读取结果。
    if _, err = zw.Write(source); err != nil {
        panic(err)
    }
    if err = zw.Close(); err != nil {
        panic(err)
    }

    // 每次只让底层 Reader 提供 3 个压缩字节。
    zr := flate.NewReader(&chunkReader{
        r:   bytes.NewReader(compressed.Bytes()),
        max: 3,
    })
    defer zr.Close()

    // ReadAll 会持续读取，直到 EOF；不会把短读当成结束。
    got, err := io.ReadAll(zr)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(got))
}

这里的关键不是 chunkReader 的实现，而是它证明了“底层每次只给一点数据”并不会改变解压结果。对于完整流，io.ReadAll 会消费到 io.EOF 并把这个正常结束转换成 err == nil。

手写循环时先处理 n，再处理 err

需要边读边处理时，可以保留同样的顺序。不要把错误判断放在数据处理之前，也不要用缓冲区是否填满来推断结束：

// readInflated 按 io.Reader 契约消费解压结果。
func readInflated(zr io.Reader, consume func([]byte) error) error {
    buf := make([]byte, 32)
    for {
        n, err := zr.Read(buf)

        // n 个字节即使与 err 同时返回，也必须先交给消费者。
        if n > 0 {
            if consumeErr := consume(buf[:n]); consumeErr != nil {
                return consumeErr
            }
        }

        // EOF 表示正常结束；其它错误需要保留给调用方。
        if err == io.EOF {
            return nil
        }
        if err != nil {
            return err
        }
    }
}

如果业务要求“必须拿到固定长度”，不要自己用 n 拼判断，可以在解压器外层使用 io.ReadFull。它会继续读取直到填满目标，若中途只读到一部分就遇到 EOF，会返回 io.ErrUnexpectedEOF，这个语义更适合固定头部或定长记录。

完整 EOF、截断流和损坏输入不是一回事

flate.NewReader 的正常 EOF 发生在最终 DEFLATE 块已被识别之后。若压缩字节在块或编码结构中途被截断，解压器不能确认一个完整的输入，调用方应保留 io.ErrUnexpectedEOF 或具体的压缩错误，而不是把所有非 nil 错误都改写成 EOF。

// decodeOne 只把完整流的 EOF 当作成功结束。
func decodeOne(compressed []byte) ([]byte, error) {
    zr := flate.NewReader(bytes.NewReader(compressed))
    defer zr.Close()

    out, err := io.ReadAll(zr)
    if err != nil {
        // 截断或损坏必须返回，让上层决定重试、丢弃还是告警。
        return nil, err
    }
    return out, nil
}

实战中可以按下面的方式解释错误：io.EOF 是正常结束信号；io.ErrUnexpectedEOF 表示结构尚未完成就没有更多输入；flate.CorruptInputError 则说明压缩编码本身在某个偏移处不符合预期。不要只记录“解压失败”，保留原始错误类型通常更有利于判断数据源问题。

底层 Reader 的两个边界

第一，若底层对象没有实现 io.ByteReader，flate 可能从它读入多于当前解压所需的数据。如果压缩流后面还拼接了另一段协议数据，不能假设这些字节仍留在原始 Reader 里；可以把底层输入包在 bufio.Reader 中，让解压器使用可回退的缓冲边界。

第二，flate.NewReader 返回的读取器实现了 flate.Resetter。复用时调用 Reset 会丢弃旧的缓冲状态，并切换到新的底层 Reader；旧流的尾部数据不能再混入新流。无论是新建还是复用，都应在完成后调用 Close，并把错误交给上层。

常见追问

为什么读到的 n 小于缓冲区长度却没有 EOF？

因为 Read 只承诺“最多返回缓冲区长度”，可用数据少于容量时可以先返回已有数据。只有错误返回值表达结束或失败，短读本身不是结束标记。

什么时候应该使用 io.ReadFull？

当协议要求固定字节数时使用；普通的解压文本或不定长内容则使用持续读取的循环或 io.ReadAll。无论哪种方式，都先处理返回的 n，不要丢掉同时返回的数据。

把短读看成 Reader 的正常形态，再把 EOF 看成解压状态的结果，flate.NewReader 的行为就不会显得反常：读取循环负责消费字节，解压器负责报告状态，业务层负责决定错误是否可重试。