Go compress/flate Writer 关闭后再次 Write 为什么返回 flate: closed writer

使用 compress/flate.Writer 时，Close 不是“暂时停一下”，而是结束当前 DEFLATE 流。关闭成功后继续调用 Write 或 Flush，返回 flate: closed writer 是生命周期约束，不是压缩级别配置错误。处理方式是把 Close 放在最后；如果还要压缩下一段独立数据，就用 Reset 切换到新的输出目标，或重新创建 Writer。

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

Go compress/flate Writer 关闭后为什么返回 flate: closed writer

flate.Writer 把输入数据编码后交给下游 io.Writer。它内部要维护压缩窗口、待输出块和流结束标记。Close 会把尚未写出的内容刷到下游，再写入 DEFLATE 的结束块；这一步完成后，当前对象代表的就是一条已经封口的压缩流。

因此，下面两种调用顺序的含义不同：

这里的“关闭”只针对压缩 Writer，不会替你关闭传入的底层 io.Writer。所以文件、连接或缓冲区的关闭责任仍由创建它的代码管理。

从 Write、Close 到再次写入看状态边界

排查时先看错误来自哪一次调用。压缩数据可能暂存在 Writer 内，所以一次 Write 返回成功，只代表输入已经被 Writer 接受；真正向下游写完尾部，往往要等 Flush 或 Close。反过来，如果底层 Writer 已经返回错误，后续调用通常会继续暴露这个错误，而不是把它误判成关闭状态。

package main

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

func main() {
    var dst bytes.Buffer
    zw, err := flate.NewWriter(&dst, flate.DefaultCompression)
    if err != nil {
        panic(err) // 级别无效时无法创建压缩器
    }

    if _, err = zw.Write([]byte("first stream")); err != nil {
        panic(err) // 输入被拒绝时立即停止后续收尾
    }
    if err = zw.Close(); err != nil {
        panic(err) // Close 负责写出尾部，不能忽略它的错误
    }

    // Close 已经结束当前流；这里的 Write 只用于展示生命周期错误。
    _, err = zw.Write([]byte("late data"))
    fmt.Println(err)
}

示例中的输出可理解为：

flate: closed writer

这个错误不应通过“再试一次同一个 Write”解决。对象已经进入终态，重试只会重复得到相同结果。生产代码应记录触发调用的阶段：是某个 defer 在显式关闭后仍写入，还是多个 goroutine 没有共享好收尾信号。

需要继续压缩时用 Reset 还是新建 Writer

如果下一段数据要成为新的独立 DEFLATE 流，可以在复用同一对象时调用 Reset(dst)。它会丢弃上一条流的状态，并把输出目标换成新的 io.Writer；新的数据必须重新经历 Write 和 Close。不要把 Reset 当成“让旧流继续追加”，它是重新初始化。

var first, second bytes.Buffer
zw, err := flate.NewWriter(&first, flate.DefaultCompression)
if err != nil {
    panic(err) // 创建失败时没有可复用的 Writer
}
if _, err = zw.Write([]byte("batch-1")); err != nil {
    panic(err) // 先处理第一段输入错误
}
if err = zw.Close(); err != nil {
    panic(err) // 第一条流必须先完整收尾
}

// Reset 开启第二条流，避免把第二段数据写进已关闭对象。
zw.Reset(&second)
if _, err = zw.Write([]byte("batch-2")); err != nil {
    panic(err) // 第二条流仍要单独检查写入错误
}
if err = zw.Close(); err != nil {
    panic(err) // 第二条流也要独立完成 Close
}

常见问题：Close、Flush 与错误处理

重复调用 Close 会怎样？

正常收尾后再次 Close 通常不会产生新的数据，也不等于可以继续 Write。代码仍应保证只有一个明确的收尾责任方。

调用 Flush 后还能 Write 吗？

可以。Flush 只是把当前待处理数据推向下游，流仍未结束；只有 Close 之后，写入才进入 closed-writer 边界。

为什么不能只检查 Write 的错误？

尾部数据可能在 Close 时才真正写出。压缩文件、网络响应和管道场景都要检查 Close 返回值，并把底层 I/O 错误与生命周期错误分开记录。