Go 怎么用 io.Pipe 连接压缩器和 HTTP 上传

需要把大文件边压缩边上传时，io.Pipe 是 Go 标准库里很顺手的连接器：生产者写入 gzip.Writer，压缩结果进入 PipeWriter，HTTP 请求从 PipeReader 读取。这样不必先把完整压缩包放进内存，也不会因为管道自带大缓冲而悄悄积压数据。

核心做法是让上传请求持有 PipeReader，另一个 goroutine 负责写入和关闭 gzip.Writer。生产端每次写入会受到网络读取速度约束；正常结束要先关压缩器，再关闭管道，异常则用 CloseWithError 把错误传给读取端。

为什么 io.Pipe 能把压缩和上传连成一条流

io.Pipe 把一个只会读的消费者和一个只会写的生产者接起来。它没有内部缓冲，一次写入要等待读端把对应数据消费掉，所以 HTTP 发送变慢时，压缩器的写入也会变慢，最终把压力传回文件读取或业务数据生成处。这正是这里需要的背压，而不是缺陷。

要注意，这种结构不是把数据“存”在 Pipe 里。PipeWriter.Write 和 PipeReader.Read 是同步配对的，因此读写两端必须由不同的执行路径推进；在同一个 goroutine 里先写满再读，会直接互相等待。

把 gzip 压缩器接到 HTTP 请求体

下面的骨架把“产生内容”的部分抽成回调，既可以写文件，也可以写 JSON 或分块导出结果。HTTP 请求只拿到读端，写端 goroutine 负责完整的关闭顺序。

func uploadStream(ctx context.Context, client *http.Client, endpoint string, produce func(io.Writer) error) error {
	// Pipe 不缓存整份内容，让网络读取速度自然形成背压。
	pipeReader, pipeWriter := io.Pipe()
	req, err := http.NewRequestWithContext(ctx, http.MethodPost, endpoint, pipeReader)
	if err != nil {
		return err
	}
	req.Header.Set("Content-Encoding", "gzip")
	req.Header.Set("Content-Type", "application/octet-stream")

	writeErr := make(chan error, 1)
	go func() {
		// 压缩器的输出直接写入 PipeWriter，不创建中间大缓冲。
		gzipWriter := gzip.NewWriter(pipeWriter)
		err := produce(gzipWriter)
		if err == nil {
			// Close 会写出 gzip 尾部，不能省略。
			err = gzipWriter.Close()
		} else {
			_ = gzipWriter.Close()
		}
		if err != nil {
			// 让 HTTP 读取端拿到真正的生产错误，而不是普通 EOF。
			_ = pipeWriter.CloseWithError(err)
		} else {
			_ = pipeWriter.Close()
		}
		writeErr = 300 {
		return fmt.Errorf("upload failed: %s", resp.Status)
	}
	return nil
}

这个函数的关键不在某个固定压缩格式，而在职责边界：生产函数只负责写，上传函数只负责请求和响应，连接两者的 goroutine 负责关闭和传错。真实项目中还要根据服务端协议补充认证、幂等键和响应体大小限制。

处理 Close、取消和错误传播

最容易漏掉的是 gzip.Writer.Close。它要写出压缩流尾部；如果直接关闭 Pipe，服务端可能读到一个看似结束、实际不完整的 gzip 流。生产函数出错时则不能只调用普通 Close，否则读端只能看到 EOF，排查时会丢失根因。

请求失败时关闭读端，是为了唤醒可能阻塞在写入上的生产 goroutine；而生产端失败时调用 CloseWithError，则是为了让 HTTP 侧尽快停止读取。两边都应最终收到错误或结束信号，不能让某一端永久等待。

长度、重试与适用边界

Pipe 产生的是运行时流，通常无法在发请求前知道压缩后的精确长度，因此不要把原文件大小写到 Content-Length。让 net/http 按未知长度发送即可。代价是请求体不可随意回放：自动重试、307/308 重定向或服务端要求重复读取时，流已经被消费，不能像 bytes.Reader 那样依靠 GetBody 重建。

如果接口强制要求精确长度、必须多次重试，或者内容本身很小，先生成临时文件或内存缓冲区更合适。反过来，大文件、导出流和不希望出现峰值内存的上传，才是 io.Pipe + gzip + HTTP 的典型边界。

相关问题

为什么写端一定要放到 goroutine 中？

因为 Pipe 没有内部缓冲，写入要等待读取；请求的读取又由客户端发送过程推进。两者放在同一条同步路径上就可能互相等待。

gzip.Close 返回错误时还要关闭 Pipe 吗？

要。先保留关闭错误，再用 CloseWithError 结束读端，让请求侧退出，最后由调用方统一处理错误。

能不能用 io.MultiWriter 同时上传和落盘？

可以，但要明确两个写目标的最慢者会共同决定背压；若落盘失败，也应及时关闭 Pipe 并取消请求。