Go flate Flush 后接收端为什么仍拿不到完整数据

我在用 compress/flate 做分段传输时，最容易误判的一点就是：发送端调用了 Flush，接收端却仍然拿不到“完整数据”。原因通常不在压缩算法失效，而在于把三个边界混在了一起：Flush 只负责把压缩器的待处理数据写到底层 Writer；网络连接没有消息边界；接收端的一次 Read 也不保证填满目标切片。

要让接收端稳定拿到一条完整消息，需要在 flate 流之上定义长度字段或其他帧格式，再用 io.ReadFull 按边界读取；如果等待流结束，还必须由发送端调用 Close。

Flush 保证了什么，没保证什么

官方文档对 Writer.Flush 的定义很明确：它把待处理的压缩数据写入底层 Writer，主要用于压缩网络协议，让远端读取到目前已经写入的数据；它等价于 zlib 的 Z_SYNC_FLUSH。这解决的是“压缩器内部还有数据没有吐出”的问题。

它没有解决另外三件事。第一，底层 Writer 可能还是一个 bufio.Writer，外层缓冲仍要单独 Flush。第二，TCP 是字节流，不保留 Write 次数，也不提供消息包边界。第三，Reader 的一次 Read 可能只返回部分字节。因此“Flush 已返回”与“接收端一次 Read 已得到完整消息”不是同一个结论。

用应用层长度字段固定接收边界

最稳妥的做法是把每条消息编码成“长度字段 + 消息体”，再把这个帧写进同一条 flate 流。下面的长度表示解压后的消息体字节数，发送端写完一帧后 Flush，接收端先读取 4 字节长度，再读取对应的消息体。

package main

import (
	"compress/flate"
	"encoding/binary"
	"fmt"
	"io"
)

// sendFrame 把一条消息写成长度字段加消息体，Flush 只负责推出压缩器缓存。
func sendFrame(zw *flate.Writer, message []byte) error {
	var header [4]byte
	// 使用大端长度，发送端和接收端必须约定同一种编码。
	binary.BigEndian.PutUint32(header[:], uint32(len(message)))
	if _, err := zw.Write(header[:]); err != nil {
		return fmt.Errorf("write frame length: %w", err)
	}
	if _, err := zw.Write(message); err != nil {
		return fmt.Errorf("write frame body: %w", err)
	}
	// 让远端看到当前帧，但不结束整个 DEFLATE 流。
	return zw.Flush()
}

// receiveFrame 先读完整长度，再读完整消息，避免把一次 Read 当成一帧。
func receiveFrame(zr io.Reader) ([]byte, error) {
	var header [4]byte
	if _, err := io.ReadFull(zr, header[:]); err != nil {
		return nil, fmt.Errorf("read frame length: %w", err)
	}
	length := binary.BigEndian.Uint32(header[:])
	if length > 4

这里的关键不是把 Flush 调得更频繁，而是让接收端知道“这一帧有多长”。长度校验也不能省：它既防止异常输入造成过大的内存分配，也能把协议错位尽早暴露出来。若业务允许，固定帧大小或带类型字段的帧头也可以采用同样的思路。

按层排查“数据不完整”

我通常按下面的顺序定位，而不是先把压缩级别从默认值改成最快。先确认 zw.Write 和 zw.Flush 的错误都被处理；再确认外层是否有 bufio.Writer，如果有，flate 写入它之后还要调用外层的 Flush。如果底层是带写缓冲的自定义 Writer，也要确认它确实把字节交给连接。

接收端则检查是否把一次 Read 当成完整帧。对于长度字段，使用 io.ReadFull；对于连续流，使用循环读取并明确退出条件。flate.NewReader 会解压连续的 DEFLATE 数据，只有遇到最终块才会返回 io.EOF，中间的 Flush 并不代表 EOF。

双层缓冲、Close 与 Flush 频率怎么取舍

如果写入链路是“flate.Writer → bufio.Writer → net.Conn”，一帧结束时的顺序通常是先调用 flate 的 Flush，再调用外层 bufio.Writer.Flush。连接关闭前再调用 flate 的 Close，这样压缩流才有最终结束标记；若外层对象也负责关闭连接，还要继续处理它的 Close 错误。

每条小消息都 Flush，实时性更好，但同步标记和系统调用会增加，压缩率也可能下降。把多条消息合并后再 Flush，吞吐和压缩率更好，却会增加等待时间。实践中可以按消息大小或几十毫秒级的批次做策略，但不要用“某次 Read 恰好读满”来证明协议正确。

常见问题

Flush 调用成功后，为什么 Read 仍只返回一部分？

因为 Reader 允许短读，且 TCP 没有消息边界。读取固定长度时使用 io.ReadFull，不要依赖一次 Read 的返回长度。

每条消息都 Close 再重新 NewWriter 可以吗？

可以形成多个独立压缩流，但会增加流初始化和协议管理成本。连续通信通常保留一个 flate.Writer，用应用层帧划分消息，最后统一 Close。

Flush 能替代 Close 吗？

不能。Flush 是中间同步点，Close 才负责完成压缩流；如果接收端要等 EOF，发送端必须在全部数据写完后 Close。

排查这类问题时，先把“压缩数据已推出”“底层连接已写出”“接收端已读满一帧”“整个流已结束”分别记录下来。四个结论都成立，接收端才能稳定得到完整消息。