Go flate.Writer 怎么用 Flush 推送实时消息

用 compress/flate 推送实时消息时，关键不是只调用 Write，而是在每条消息或一小批消息写入后调用 Flush。Write 可能只更新压缩器的内部状态；Flush 才会把当前可解码的数据和同步标记写到底层 io.Writer。发送结束时再调用一次 Close，让接收端知道 DEFLATE 流已经收尾。

最小可靠组合是：发送端写入一条长度帧，调用 Flush；接收端用 flate.NewReader 解压，再用 io.ReadFull 读取长度和正文。Flush 能推动压缩流，不等于网络层确认，也不会替你设计消息边界。

先分清 Write、Flush 和 Close 的职责

flate.Writer 的输出目标可以是 io.PipeWriter、HTTP 响应或自定义网络 writer。Write 返回成功，只说明数据被压缩器接受；它不保证对端现在就能读到完整消息。Flush 会把待处理数据写入底层 writer，在 zlib 术语中相当于 Z_SYNC_FLUSH。即使没有待处理数据，它仍可能产生至少 4 字节的同步标记，因此不适合无条件地每个空循环都调用。

用长度帧把实时消息分开

压缩流本身只负责还原字节，不会替应用自动恢复“这一条消息在哪里结束”。可以在每条消息前写一个长度字节，形成 [1 byte length][payload]。下面用 io.Pipe 模拟持续传输，代码中的中文注释说明了刷新、关闭和错误处理的关键点。

package main

import (
    "compress/flate"
    "fmt"
    "io"
    "log"
    "strings"
)

func main() {
    rp, wp := io.Pipe()

    go func() {
        // 用 BestSpeed 减少实时发送的压缩等待；生产环境可按数据特征调整级别。
        zw, err := flate.NewWriter(wp, flate.BestSpeed)
        if err != nil {
            _ = wp.CloseWithError(err)
            return
        }

        for _, msg := range strings.Fields("alpha beta gamma") {
            frame := append([]byte{byte(len(msg))}, msg...)
            // Write 只把帧交给压缩器，尚未承诺接收端立即可读。
            if _, err := zw.Write(frame); err != nil {
                _ = wp.CloseWithError(err)
                return
            }
            // Flush 推送当前同步边界，让读端可以解出这条帧。
            if err := zw.Flush(); err != nil {
                _ = wp.CloseWithError(err)
                return
            }
        }
        // Close 负责最终 DEFLATE 收尾；只在所有消息发送后调用一次。
        if err := zw.Close(); err != nil {
            _ = wp.CloseWithError(err)
            return
        }
        _ = wp.Close()
    }()

    zr := flate.NewReader(rp)
    defer zr.Close()
    buf := make([]byte, 255)
    for {
        // 每次先读长度，EOF 表示发送端已经 Close 并正常结束。
        if _, err := io.ReadFull(zr, buf[:1]); err != nil {
            if err == io.EOF {
                break
            }
            log.Fatal(err)
        }
        n := int(buf[0])
        // 再读正文，避免一次 Read 返回半条消息。
        if _, err := io.ReadFull(zr, buf[:n]); err != nil {
            log.Fatal(err)
        }
        fmt.Println(string(buf[:n]))
    }
}

这个例子里的帧长度限制为 255 字节，是为了让协议足够直观。真实业务可以改成两个或四个字节的无符号长度，并限制最大值，避免异常输入让接收端分配过大的缓冲区。

Flush 的调用位置与错误边界

发送顺序应保持为“写完整帧 → Flush → 继续下一帧”。如果 Write 或 Flush 返回错误，应停止继续写入，并把错误传递给底层 pipe 或连接；继续刷新已经失败的流只会让故障更难定位。接收端先读长度再读正文，io.ReadFull 遇到非 EOF 错误时应作为传输失败处理，而不是把半条消息交给业务层。

另外，Flush 只保证数据已经交给底层 writer。HTTP 服务还可能受到响应缓冲、代理和客户端读取策略影响，所以“服务端调用了 Flush”不等于浏览器立刻渲染。若需要可观测性，应在应用协议中加入消息序号或心跳，而不是把 Flush 当作确认包。

实时性和压缩率怎么取舍

因此，聊天片段、日志事件这类小消息可以按条或按短时间窗口刷新；批量文件则应减少 Flush 次数，把 Close 留给真正的结束点。

常见问题

Flush 后为什么仍然读不到数据？

先确认读端已经创建 flate.NewReader 并持续读取，再检查底层 writer 是否被代理或响应缓冲包住。Flush 只作用于压缩器到 writer 这一层。

可以用 Flush 代替 Close 吗？

不能。Flush 产生同步边界，Close 才完成最终压缩流收尾并关闭 writer；持续消息用 Flush，传输结束仍要 Close。

速记：为消息设计帧，用 Write 写完整帧，用 Flush 推进实时性，用 Close 表示结束；同时为每次底层写入保留错误路径。