Go 如何流式转发 multipart 文件而不落盘

Go 要把一个 multipart/form-data 上传请求转发给上游，又不想把文件全部读进内存或写入临时目录，核心方案是：用 multipart.Reader.NextPart 逐段读取入站请求，用 io.Pipe 连接 multipart.Writer 和上游请求体。这样每段数据边读边写，管道还能把上游的读取速度反馈给写入端。

先把问题拆成入站流、管道和上游流

mime/multipart 的 Reader 是按需消费输入的迭代器，NextPart 返回下一段，直到 io.EOF。这正适合网关场景：入站请求体是源，Part 是当前字段或文件，输出端再用新的 writer 生成完整的 multipart 边界。

这里不要使用 ReadForm 来“先解析再转发”。官方文档说明，ReadForm 会把非文件字段放在内存里，无法放入内存的文件部分会写到临时文件；它解决的是表单解析，不是零落盘转发。

用 io.Pipe 把读取速度变成背压

下面的函数只展示代理核心。示例保留每个 part 的头部，文件内容通过 io.Copy 直接写向上游；代码中的注释说明了错误和资源关闭位置。

func proxyMultipart(w http.ResponseWriter, r *http.Request) {
    mediaType, params, err := mime.ParseMediaType(r.Header.Get("Content-Type"))
    if err != nil || mediaType != "multipart/form-data" || params["boundary"] == "" {
        http.Error(w, "invalid multipart content type", http.StatusBadRequest)
        return
    }

    pipeReader, pipeWriter := io.Pipe()
    writer := multipart.NewWriter(pipeWriter)
    req, err := http.NewRequestWithContext(
        r.Context(), http.MethodPost, "https://upload.internal.example/api/files", pipeReader,
    )
    if err != nil {
        _ = pipeReader.CloseWithError(err)
        return
    }
    // 新请求必须使用新 writer 的 boundary，不能直接照搬入站 Content-Type。
    req.Header.Set("Content-Type", writer.FormDataContentType())

    copyDone := make(chan error, 1)
    go func() {
        defer close(copyDone)
        reader := multipart.NewReader(r.Body, params["boundary"])
        for {
            part, nextErr := reader.NextPart()
            if nextErr == io.EOF {
                break
            }
            if nextErr != nil {
                copyDone 

io.Pipe 是同步内存管道：写入会等待读取端消费，默认没有内部缓冲。因此复制 goroutine 和 http.Client.Do 必须同时存在；如果在调用 Do 前顺序写完整个请求，写端会先阻塞。

逐段复制时要守住边界和错误

每次 NextPart 得到的对象既有字段名、文件名等头部，也有当前段的读取流。CreatePart 负责把这些头部写进新的 multipart 消息，io.Copy 只搬运当前段；循环结束后必须调用 writer.Close，否则上游可能看不到结束边界。

错误要沿反方向传播：解析失败、创建 part 失败或复制失败时，用 pipeWriter.CloseWithError 让上游读取端得到错误；上游请求先失败时，再关闭 pipeReader，解除写端阻塞。请求使用 r.Context() 后，客户端断开也能让上游请求跟随生命周期取消。

流式转发的参数边界与检查清单

这个方案的“零落盘”是指转发路径不主动创建临时文件，并不代表内核、代理层或上游永远不会缓存。若要限制请求大小，可以在进入解析器前包一层 http.MaxBytesReader；若需要重试，则要重新获得可读源，通常意味着对象存储临时对象或可重复读取的文件，而不是继续复用同一个 pipe。

相关问题

为什么不能直接把 r.Body 同时交给上游请求？

可以在完全不修改 multipart 内容时直接复用，但网关就无法逐段检查、过滤或改写字段。需要保留边界控制或处理错误时，应使用本文的 reader-writer 管道。

io.Pipe 会不会把整个文件放在内存里？

不会。它没有内部缓冲，写端和读端同步匹配；真正的内存占用取决于两端及 HTTP 传输层的少量缓冲。

为什么 writer.Close 不能省略？

multipart 消息的结束边界由 writer 负责写出。省略它时，上游可能一直等待剩余内容，或者把请求判为格式不完整。