multipart上传大文件内存暴涨怎么办

Go 服务端接收 multipart 大文件时，先检查是否把整个请求或文件内容放进了 bytes.Buffer、io.ReadAll 或大的字节切片。只需逐个处理文件时，可使用 Request.MultipartReader 与 NextPart，把文件分块写入存储，同时限制请求体总量、单文件大小和并发上传数。降低 ParseMultipartForm 的 maxMemory 不能代替这些限制。

官方地址：https://pkg.go.dev/net/http#Request.MultipartReader

项目目标：接收一个文件，不把它整体留在内存

本文制作一个最小接收器：POST /upload 只接受一个名为 file 的文件 part，单文件最多 32 MiB，请求体最多 33 MiB，为 multipart 头和边界留出空间。文件使用服务器生成的随机名称，失败时删除半成品。它是流式接收原型，不包含鉴权、文件内容审查或正式下载服务。

ParseMultipartForm 会解析整个表单，将一部分文件内容放内存，剩余内容放临时文件。它的 maxMemory 是解析时的内存策略参数，不是整个请求的最大字节数，也不是进程内存硬上限。即便解析阶段把文件放到磁盘，随后 ReadAll 文件内容，仍会重新把它完整载入内存。

准备存储目录和资源限制

存储目录应由服务端控制，并放在公开静态目录之外。客户端文件名仅是元数据，不应用作服务端路径。下面使用 os.CreateTemp 创建随机文件；成功文件保留在目录中，后续正式业务应再登记元数据并安排保留策略。

核心代码：分块写盘并清理失败文件

保存为 main.go。示例只监听本机地址，工作目录需可写。为保持原型简洁，错误默认按格式错误返回，文件系统错误按服务器错误返回，大小超限返回 413。生产项目可进一步定义自己的错误类型。

package main

import (
    "errors"
    "fmt"
    "io"
    "log"
    "net/http"
    "os"
    "time"
)

const fileLimit int64 = 32  fileLimit {
        return "", errTooLarge
    }
    // 文件已读完，再确认没有额外 part；不忽略损坏的结束边界。
    extra, err := mr.NextPart()
    if err == nil {
        _ = extra
        return "", errors.New("仅允许一个文件 part")
    }
    if !errors.Is(err, io.EOF) {
        return "", err
    }
    if err := f.Close(); err != nil {
        return "", err
    }
    keep = true
    return f.Name(), nil
}

func upload(w http.ResponseWriter, r *http.Request) {
    if r.Method != http.MethodPost {
        w.Header().Set("Allow", http.MethodPost)
        http.Error(w, "仅允许 POST", http.StatusMethodNotAllowed)
        return
    }
    // 限制实际读取规模，不仅检查客户端提供的 Content-Length。
    r.Body = http.MaxBytesReader(w, r.Body, requestLimit)
    defer r.Body.Close()

    _, err := saveOne(r, "./upload-data")
    if err != nil {
        status := http.StatusBadRequest
        var maxErr *http.MaxBytesError
        var diskErr *os.PathError
        switch {
        case errors.Is(err, errTooLarge), errors.As(err, &maxErr):
            status = http.StatusRequestEntityTooLarge
        case errors.As(err, &diskErr):
            status = http.StatusInternalServerError
        }
        log.Printf("上传失败: %v", err)
        http.Error(w, "上传未完成", status)
        return
    }
    // 不向调用方回显服务器文件路径。
    w.WriteHeader(http.StatusCreated)
}

func main() {
    if err := os.MkdirAll("./upload-data", 0700); err != nil {
        log.Fatal(err)
    }
    mux := http.NewServeMux()
    mux.HandleFunc("/upload", upload)
    server := &http.Server{
        Addr: "127.0.0.1:8080", Handler: mux,
        ReadHeaderTimeout: 5 * time.Second,
        ReadTimeout: 60 * time.Second,
    }
    log.Fatal(server.ListenAndServe())
}

超限退出时，示例不尝试无限排空当前 part，而是关闭整个请求体，并清理半成品。读取过程中最多为单文件写入上限加一个字节。multipart 解析器与 HTTP 层还会使用自己的缓冲，操作系统也有页缓存，所以不能把 32 KiB 业务复制缓冲描述成每请求或整个进程的全部内存。

MultipartReader 与 ParseMultipartForm 是两种处理方式，不应先让中间件调用 FormFile 或 ParseMultipartForm，再指望这里从原始请求重新流式处理。检查框架的自动表单解析、请求日志和代理缓存，同样可能发现全量缓冲来源。

本地运行与预期结果

# 在保存 main.go 的目录启动示例服务。
go run main.go

# 在另一个命令会话上传自备文件，让 curl 自动生成 boundary。
curl -i -F 'file=@./sample.bin' http://127.0.0.1:8080/upload

示例命令供读者自行运行，本文没有启动服务、上传文件或提供伪造内存数据。合理大小且 multipart 完整的单文件请求，预期返回 201；超限预期返回 413；字段不对、出现第二个 part 或结束边界损坏，应失败并删除已经创建的半成品。

不要手动把 Content-Type 只设置成 multipart/form-data 却遗漏 boundary；curl 的 -F 会生成所需头和边界。成功文件留在 upload-data 目录中，例子不会提供公开访问入口。若失败清理又遇到磁盘错误，日志会记录，运维仍需要孤儿文件清理机制。

部署集成与验收边界

反向代理可能先缓存请求体，应用流式写盘并不自动改变代理策略。应按业务决定是否允许缓冲，并让代理与应用限额相互协调。磁盘容量、写入吞吐和成功文件的保留期限也需要监控。

示例没有添加并发闸门。生产环境应限制同时进入上传接收器的请求数，超过容量时排队或拒绝，并按租户设置配额。并发翻倍时，即使每个请求只用有限缓冲，连接、解析器、文件描述符和磁盘写入仍会叠加。ReadTimeout 是示例的整个请求读取时间预算，真实大文件场景应按最低传输速度与服务目标重新制定，不能照抄 60 秒。

验收至少覆盖合理大小文件、边界附近文件、超限、客户端中断、磁盘不可写和多 part 输入。观察进程堆与系统内存要区分 Go 对象和页缓存；记录相同并发和文件规模下的数据再比较，不能仅凭一个峰值就断言泄漏。

ParseMultipartForm(0) 就完全不用内存吗？

不是。解析元数据、普通字段和运行时缓冲仍会占用内存。该参数不是零内存保证。

流式写盘后还需要临时文件清理吗？

需要。本文主动创建的文件由应用负责；若使用表单整体解析产生临时文件，还应按其生命周期调用 MultipartForm.RemoveAll。

客户端上传时也内存暴涨怎么办？

还要检查发送端是否先构造了完整 multipart 缓冲。本文只处理服务端接收，不能据此认定发送端也已经流式化。

官方参考：https://pkg.go.dev/net/http#Request.MultipartReader；表单解析说明：https://pkg.go.dev/net/http#Request.ParseMultipartForm；分块读取：https://pkg.go.dev/mime/multipart#Reader.NextPart。