Go compress/flate.Writer.Flush 为什么会影响流式响应延迟

如果你把 compress/flate.Writer 当成普通的 io.Writer，很容易遇到一个现象：调用 Write 已经返回了，但接收端还没有看到这段流式内容。原因是写入先进入压缩器，压缩器再决定何时把压缩数据交给下游。Flush 的作用，就是把当前待写数据推到下游，并建立一个接收端可以继续读取的同步边界。

因此，Flush 能降低“数据已经产生却迟迟不可见”的等待感，但它不是越多越好。每次刷新都可能触发实际写出；即使没有待写数据，也会产生至少 4 字节的同步标记。流式响应应把刷新放在一段完整消息或可消费片段的边界，而不是每个很小的 Write 后面。

Flush 到底刷新了什么

Write 只保证数据交给 flate.Writer 处理，压缩后的字节什么时候交给底层 io.Writer，由压缩器的缓冲和压缩块组织决定。Flush 会等待数据写入底层 writer 后才返回；底层 writer 出错时，错误也会从 Flush 返回。

下面的示例把每条消息视作接收端可以独立消费的片段。注释只解释关键边界，示例本身不代表某个真实服务的运行截图。

func writeStream(dst io.Writer, messages []string) error {
	// 创建压缩写入器，压缩结果交给下游 writer。
	zw, err := flate.NewWriter(dst, flate.DefaultCompression)
	if err != nil {
		return err
	}

	for _, message := range messages {
		// 一次 Write 写入一条逻辑消息，不把小片段拆成多次刷新。
		if _, err := zw.Write([]byte(message)); err != nil {
			_ = zw.Close()
			return err
		}
		// Flush 让这条消息对应的压缩数据尽快交给下游。
		if err := zw.Flush(); err != nil {
			_ = zw.Close()
			return err
		}
	}
	// Close 负责写出剩余数据并结束 DEFLATE 流。
	return zw.Close()
}

这个边界有两个容易忽略的含义：第一，Flush 解决的是“压缩层何时把数据交出去”，不是自动替你刷新所有更外层的缓冲；第二，Close 仍然必须调用，因为它负责结束压缩流并写出最后一段数据。

为什么 Flush 调得越勤，延迟不一定越低

频繁刷新会把压缩输出切成更多同步边界。对长连接来说，较早的同步边界通常意味着接收端更早获得可读取的数据；但边界越多，压缩器可利用的连续数据越少，同时每次刷新都可能产生额外写出。特别是“没有新数据也调用 Flush”的代码，会重复付出同步标记的代价。

工程上可以先定义“读者什么时候需要看到内容”：例如一条完整事件、一个进度片段或一批可渲染文本。只有到达这个边界才刷新。这样既能避免每个 token、每个字段都触发一次写出，也不会为了等待压缩器自行积累而让整段响应一直沉默。

如果下游还有 bufio.Writer，需要把刷新顺序想清楚：先刷新 flate.Writer，再刷新外层缓冲。否则压缩器虽然已经把字节交给了 bufio.Writer，网络或管道仍可能看不到它。

func writeBuffered(dst io.Writer, message string) error {
	buffered := bufio.NewWriter(dst)
	zw, err := flate.NewWriter(buffered, flate.DefaultCompression)
	if err != nil {
		return err
	}

	// 先把压缩层的待写数据交给外层缓冲。
	if _, err := zw.Write([]byte(message)); err != nil {
		_ = zw.Close()
		return err
	}
	if err := zw.Flush(); err != nil {
		_ = zw.Close()
		return err
	}
	// 再把外层缓冲交给真正的下游 writer。
	if err := buffered.Flush(); err != nil {
		_ = zw.Close()
		return err
	}
	// 结束时先关闭压缩器，生产环境还应处理 Close 的返回错误。
	return zw.Close()
}

示例中的外层缓冲只用于说明刷新层级。实际项目如果下游是 HTTP 响应，还要根据所用框架的响应刷新接口处理网络层；不要把压缩器的 Flush 误认为“客户端已经完成渲染”。它只能说明压缩层已把数据写给下游。

把首字节延迟和压缩效率放在同一张表里

可以把判断压缩成一句话：需要让下游继续读，就在可消费边界调用 Flush；不需要中途可见，就让压缩器积累数据，最后用 Close 完成收尾。不要用增加刷新次数的方式掩盖外层缓冲没有刷新的问题。

常见问题

Flush 会关闭 flate.Writer 吗？

不会。它刷新当前待写数据并保留 writer 继续写入；完整结束仍应调用 Close。

没有调用 Flush，Write 返回成功是不是数据丢了？

不是。数据可能仍在压缩器或更外层缓冲中。若读者需要流式看到中间结果，应建立明确的刷新边界，并检查每一层的错误。