Go compress/flate Writer.Close 怎样完成压缩流收尾

Go 的 compress/flate 是一个把输入写成 DEFLATE 压缩流的 io.Writer。容易被忽略的一点是：Write 只是接收数据，数据可能仍停留在压缩器内部；要把完整压缩流交给底层 Writer，通常必须显式调用 Close 并检查它的错误。

官方文档：https://pkg.go.dev/compress/flate#Writer.Close

Write 成功不等于压缩流已经完成

flate.Writer 会把输入组织成压缩块，再交给创建它时传入的底层 io.Writer。因此，调用 Write 返回成功，只能说明输入已经被压缩器接收；底层输出是否已经包含最后一段数据，还取决于后续的刷新和收尾。

官方文档对 Close 的定义很短，但含义很关键：它会 flush 并关闭 Writer。这里的“关闭”不是把文件或网络连接一并关闭，而是结束 *flate.Writer 自己的压缩写入生命周期；底层 Writer 仍由调用方管理。

完整压缩结果要把 Close 放在最后

文件和内存场景通常需要一段完整的压缩结果。最小写法是先创建 Writer，写入全部输入，再检查 Close：

package main

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

func compressText(input []byte) ([]byte, error) {
    var dst bytes.Buffer

    // DefaultCompression 使用默认压缩级别；底层 Buffer 不会被 flate.Close 关闭。
    zw, err := flate.NewWriter(&dst, flate.DefaultCompression)
    if err != nil {
        return nil, fmt.Errorf("创建压缩器失败: %w", err)
    }

    // Write 返回的错误表示压缩器或底层 Writer 已经遇到写入问题。
    if _, err := zw.Write(input); err != nil {
        return nil, fmt.Errorf("写入压缩数据失败: %w", err)
    }

    // Close 负责最终 flush；必须检查它，因为尾部写出也可能失败。
    if err := zw.Close(); err != nil {
        return nil, fmt.Errorf("完成压缩流失败: %w", err)
    }
    return bytes.Clone(dst.Bytes()), nil
}

func main() {
    compressed, err := compressText([]byte("一段需要完整收尾的文本"))
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println("压缩字节数:", len(compressed))
}

如果忽略 Close 返回值，最容易出现的误判是“输入已经全部写入，所以输出肯定完整”。当底层 Writer 在最后一次写入时失败，真正可靠的错误可能只会在 Close 阶段暴露。

Write 和 Close 的错误要分开处理

压缩器的输入路径和最终收尾路径都可能写到底层 Writer。为了说明这一点，可以让底层 Writer 在达到字节上限后返回错误；这个示例不依赖具体文件或网络环境，只展示错误如何沿调用链返回：

type limitedWriter struct {
    dst bytes.Buffer
    left int
}

func (w *limitedWriter) Write(p []byte) (int, error) {
    // 模拟磁盘已满或网络写端失败，限制底层最多接受的字节数。
    if w.left == 0 {
        return 0, io.ErrShortWrite
    }
    n := len(p)
    if n > w.left {
        n = w.left
    }
    _, _ = w.dst.Write(p[:n])
    w.left -= n
    if n != len(p) {
        return n, io.ErrShortWrite
    }
    return n, nil
}

func compressToLimitedWriter(input []byte, limit int) error {
    out := &limitedWriter{left: limit}

    // flate 只拥有 out 这个 Writer 的写入关系，不会替调用方关闭 out。
    zw, err := flate.NewWriter(out, flate.BestSpeed)
    if err != nil {
        return fmt.Errorf("创建压缩器失败: %w", err)
    }
    if _, err := zw.Write(input); err != nil {
        // 输入阶段已经失败时，仍可记录原始错误并结束当前压缩任务。
        return fmt.Errorf("压缩写入失败: %w", err)
    }
    if err := zw.Close(); err != nil {
        // 最后的压缩块和结束信息写不出去时，Close 是最终错误出口。
        return fmt.Errorf("压缩收尾失败: %w", err)
    }
    return nil
}

生产代码中不要把 Close 错误覆盖掉，也不要只依赖 Write 的返回值。若错误来自外层文件、HTTP 响应或自定义 Writer，建议在错误信息里保留操作阶段，方便判断是输入阶段失败还是收尾阶段失败。

Flush 适合中途交付，Close 才是最终结束

Flush 会把当前待处理数据写到底层 Writer，并发送同步标记；它主要用于压缩网络协议，使接收端可以继续读取一段已经提交的数据。因为后面还可能继续写入，所以 Flush 不能替代完整消息结束时的 Close。

可以把三个动作理解成不同的生命周期节点：

复用 Writer 前先完成 Close，再调用 Reset

Reset(dst) 会丢弃当前 Writer 的状态，并让它像使用相同压缩级别重新创建一样指向新的目标。它适合降低重复创建压缩器的成本，但前提是上一段压缩流已经完成；如果上一段还没有 Close，直接 Reset 会把尚未收尾的数据留在旧目标中。

func compressTwoMessages(first, second []byte) ([]byte, []byte, error) {
    var firstDst, secondDst bytes.Buffer

    // 第一次压缩绑定第一个目标，并在 Reset 前完成最终收尾。
    zw, err := flate.NewWriter(&firstDst, flate.DefaultCompression)
    if err != nil {
        return nil, nil, err
    }
    if _, err := zw.Write(first); err != nil {
        return nil, nil, err
    }
    if err := zw.Close(); err != nil {
        return nil, nil, err
    }

    // Reset 复用压缩器，但不会替调用方检查上一段 Close 的错误。
    zw.Reset(&secondDst)
    if _, err := zw.Write(second); err != nil {
        return nil, nil, err
    }
    if err := zw.Close(); err != nil {
        return nil, nil, err
    }
    return bytes.Clone(firstDst.Bytes()), bytes.Clone(secondDst.Bytes()), nil
}

这里每段消息都有独立的底层输出和独立的 Close。如果目标是连续的网络协议流，则应根据协议设计决定什么时候 Flush、什么时候结束连接或结束压缩流，不要把“复用 Writer”误认为“把多个逻辑消息自动合并成可独立解码的文件”。

把压缩收尾动作放进调用清单

• 创建时检查压缩级别错误，合法范围是 -2 到 9。
• 每次 Write 都保留错误，不把短写或底层错误静默吞掉。
• 完整文件、内存结果或完整消息交付前，一定检查 Close。
• 中途让接收端继续读取时使用 Flush，但最后仍按协议完成 Close。
• 只有上一段已经结束且不再写入旧目标时，才使用 Reset。
• 不要在测试中依赖底层输出的精确字节序列；应通过解压后的内容和错误行为判断结果。

常见问题

调用 flate.Writer.Close 会把底层文件也关闭吗？

不会。Close 结束的是 flate Writer 自己的压缩写入状态，底层文件、网络连接或 bytes.Buffer 仍由创建者管理。

已经调用 Flush，为什么还要 Close？

Flush 只提交当前可刷新的部分并保留继续写入的能力；Close 负责最终压缩流收尾。完整结果交付前不能只调用 Flush。

Close 出错后还能 Reset 继续复用吗？

不要把它当成无条件安全的恢复手段。先记录 Close 的真实错误并放弃当前输出；只有确认调用方的错误策略允许复用时，才在清晰的生命周期边界上 Reset。