Go io.Pipe 适合怎样连接生产者和上传请求

Go 的 io.Pipe 适合把“还在生成的数据”直接交给 HTTP 上传请求：生产者写入 *io.PipeWriter，请求体读取 *io.PipeReader，中间不需要先把完整文件放进内存或临时文件。最重要的不是把两端接上，而是明确三种结束方式：成功时由写端 Close() 发出 EOF，生产失败时用 CloseWithError(err) 传递原因，请求提前停止消费时关闭读端解除写端阻塞。

把 io.Pipe 当作同步的流式边界：HTTP 请求负责消费，生产 goroutine 负责写入，且只能由生产者决定正常结束或报告生产错误。请求返回错误后，调用 PipeReader.CloseWithError，再等待生产 goroutine 退出。

先把生产者和请求体放在同一条管道上

io.Pipe() 返回读端和写端。读端可以交给 http.NewRequestWithContext 作为请求体，写端留给另一个 goroutine。因为管道是同步的，生产者不会无限制地把数据堆在内存里；当服务端或网络消费变慢时，写入自然形成背压。

这也意味着两端必须同时推进。只创建管道却不启动写端，HTTP 请求会等待请求体数据；只写入却没有请求读取，生产 goroutine 也可能卡在 Write。因此，管道适合“生成速度和上传速度可以并行”的场景，不适合作为需要随机读取的文件替代品。

用 multipart.Writer 完成一次流式上传

下面的示例把一个输入流作为文件字段上传。multipart.Writer 先写字段头和文件内容，最后必须调用自身的 Close() 写入 multipart 结束边界；这一步完成后，才适合关闭 PipeWriter 告诉请求体“没有更多字节”。

package upload

import (
    "context"
    "fmt"
    "io"
    "mime/multipart"
    "net/http"
)

func Upload(ctx context.Context, endpoint, filename string, src io.Reader) error {
    pr, pw := io.Pipe()

    req, err := http.NewRequestWithContext(ctx, http.MethodPost, endpoint, pr)
    if err != nil {
        // 请求没有创建成功时没有生产 goroutine，直接关闭读端即可。
        _ = pr.Close()
        return err
    }
    form := multipart.NewWriter(pw)
    req.Header.Set("Content-Type", form.FormDataContentType())

    producerDone := make(chan error, 1)
    go func() {
        // 这个 goroutine 是 PipeWriter 的唯一拥有者，负责三种终态。
        part, err := form.CreateFormFile("file", filename)
        if err == nil {
            // Copy 出错时不要发送正常 EOF，要把原因传到读取端。
            _, err = io.Copy(part, src)
        }
        if err == nil {
            // 先补 multipart 结束边界，再让整个请求体得到 EOF。
            err = form.Close()
        }
        if err != nil {
            _ = pw.CloseWithError(err)
            producerDone 

这里的 form.Close() 和 pw.Close() 是两件事：前者结束 multipart 格式，后者结束管道字节流。Content-Type 中包含边界参数，不能手写成不带 boundary 的固定值。

关闭顺序决定错误能否传回调用方

正常路径应是“写完内容 → 关闭 multipart → 关闭 PipeWriter”。读端读到 EOF 后，HTTP 传输可以完成请求。生产路径出错时则改用 pw.CloseWithError(err)，这样读取端不会把一个半截请求误认为正常结束。

反方向的请求失败也要处理。比如服务端提前断开连接，Do 返回后请求体可能不再继续读，生产者下一次写入就会等待。此时关闭 pr，写端会收到关闭错误并退出；通过有缓冲的 producerDone 等待它完成，可以把 goroutine 生命周期收束在 Upload 返回之前。

哪些场景不适合直接使用 io.Pipe

另外，io.Pipe 本身不响应 context.Context 的取消；上下文只是让 HTTP 客户端停止请求，代码仍要负责关闭管道端点。若生产源也支持取消，应在源读取处同时检查上下文，让它尽快停止计算或 I/O。

常见问题

为什么写端调用 Close 后读端得到 EOF？

这是正常结束信号，表示写端不会再产生字节。如果是生产过程失败，应使用 CloseWithError，否则调用方只会看到一个正常的 EOF。

可以给 PipeWriter 加 defer Close 吗？

更建议明确区分成功和失败分支。无条件的延迟关闭容易让代码读不出“错误已经通过 CloseWithError 发送”的意图，也可能在资源所有权变化时掩盖收尾问题。

HTTP 上传一定要用 multipart 吗？

不一定。若接口接收原始字节流，可以直接把 PipeReader 作为请求体；只有需要文件字段、表单字段和 boundary 时才使用 multipart.Writer。

参考资料：https://pkg.go.dev/io#Pipe、https://pkg.go.dev/io#PipeWriter.CloseWithError、https://pkg.go.dev/net/http#NewRequestWithContext、https://pkg.go.dev/mime/multipart#Writer.Close