Go io.Pipe 如何把压缩输出直接接到上传请求

上传几十 MB 的压缩文件时，先把完整结果写进内存或落到临时文件，往往只是把等待时间换成磁盘和内存压力。更直接的做法是让 gzip.Writer 写入 io.PipeWriter，HTTP 客户端从对应的 io.PipeReader 读取：压缩输出产生一段，请求就发送一段。

io.Pipe 只负责把写端和读端接起来，不会替你处理协程错误。生产代码必须明确 gzip 的关闭顺序、请求结束信号，以及如何把压缩失败传给 HTTP 客户端。

先看清楚三段数据是怎样流动的

这段链路可以拆成三个角色：业务数据写入 gzip.Writer，gzip.Writer 把压缩后的字节写入 pipe，http.NewRequest 再把 pipe 的读端当作请求体。HTTP 客户端读取得慢时，pipe 的写入会反过来等待，这就是天然的背压。

不要把 io.Pipe 当作一个带缓冲的队列。写端和读端是一对同步接口，读端没有继续消费时，写端可能停在下一次写入上。这个特性正好能限制内存，但也意味着上传协程必须被可靠地启动和回收。

最小可用写法：gzip 输出直接进入请求体

下面的函数只演示链路，不绑定具体业务文件格式。调用方传入一个写入原始数据的函数，函数内部创建新的 pipe、gzip.Writer 和请求；每次上传都要创建这一整套对象。

func uploadGzip(ctx context.Context, client *http.Client, endpoint string, writeData func(io.Writer) error) error {
    pr, pw := io.Pipe()
    gz := gzip.NewWriter(pw)

    req, err := http.NewRequestWithContext(ctx, http.MethodPost, endpoint, pr)
    if err != nil {
        _ = pr.Close()
        _ = pw.Close()
        return err
    }
    req.Header.Set("Content-Type", "application/gzip")

    writeDone := make(chan error, 1)
    go func() {
        if err := writeData(gz); err != nil {
            _ = gz.Close()
            _ = pw.CloseWithError(err)
            writeDone = 300 {
        return fmt.Errorf("upload failed: %s", resp.Status)
    }
    return nil
}

这里的顺序有两个关键点：gz.Close() 会写出 gzip 尾部，不能省略；writeDone 使用带一个缓冲的 channel，保证 HTTP 客户端提前返回时，写入协程仍能把最终错误交给调用方。

关闭顺序决定了文件是否完整

成功路径应当是“业务写完 → 关闭 gzip → 关闭 pipe”。如果直接关闭 pipe，gzip 尾部可能还没写出去，服务端解压时就会看到截断流。失败路径则不能只返回错误，因为读端可能仍在等待数据，应该用 CloseWithError 唤醒它。

这几个边界最容易让实现失真

只返回 HTTP 状态，不等待写入协程

服务端返回状态时，生产端可能仍在写最后一段数据。若此时函数直接返回，压缩错误会被吞掉。无论请求先结束还是写入先结束，都要等待 writeDone，并按业务需要区分客户端取消、服务端断开和本地编码失败。

把 pipe 和 gzip 放到函数外复用

pipe 是一次性连接，读端关闭后不能“清空再用”。重试必须重新创建 pipe、gzip.Writer 和请求体；否则第二次请求可能读到已结束的流，或者把上一次的关闭错误带进来。

给流式请求强行设置错误的长度

普通的 pipe 请求通常让 HTTP 客户端采用分块传输。只有在能够提前得到压缩后准确长度时才设置 Content-Length；不能因为原始文件大小已知，就把它当成压缩流长度。

上线前用一张清单做反向验证

• 输入函数写入多段数据后，服务端解压结果与原始内容一致。
• 输入函数中途返回错误时，调用方能拿到该错误，且请求不会永久阻塞。
• 客户端取消 context 后，写入方能结束，不留下等待 pipe 的 goroutine。
• 重试场景每次都创建新的 pipe、gzip.Writer 和 Request。

常见问题

io.Pipe 会不会把完整压缩内容放进内存？

不会。它主要提供读写同步，内存占用取决于上下游正在处理的数据和 HTTP 客户端缓冲，而不是完整文件大小。

为什么一定要调用 gzip.Writer.Close？

gzip 的尾部校验和尺寸信息在关闭时写出。缺少这一步，服务端可能把请求当成截断的 gzip 数据。

上传失败后能直接复用原来的请求体重试吗？

不能。请求体已经被消费，应该重新创建 pipe 和压缩流程；如果原始数据不可重复读取，还要先设计可重放的数据源。

总结

io.Pipe 的价值是把压缩输出和网络发送连接起来，同时用背压控制内存。真正容易出错的不是创建对象，而是没有处理关闭顺序、错误唤醒和协程收尾。把这三处写清楚，再用可解压结果和失败注入测试验收，流式上传才算完整。