Go multipart.Reader ReadForm 怎么控制内存占用

处理 multipart/form-data 上传时，真正稳妥的做法不是只把 ReadForm 的参数调小，而是同时控制三层边界：先用 http.MaxBytesReader 限制请求总大小，再用 ReadForm(maxMemory) 约束表单解析预算，最后在请求结束时调用 Form.RemoveAll() 清理可能创建的临时文件。

官方文档：https://pkg.go.dev/mime/multipart

maxMemory 不是“整个上传请求最多占用多少内存”。官方定义是：文件部分最多尽量在内存中保存 maxMemory 字节，非文件字段还会保留约 10MB 的额外空间；放不下的文件内容会写入临时文件。因此生产接口要把请求上限、字段预算和临时文件清理一起设计。

先分清三种大小：请求、字段和文件缓存

ReadForm(maxMemory) 会解析整个 multipart 消息，并返回 Form。普通字段存放在 Form.Value，文件字段通过 Form.File 和 FileHeader.Open() 访问。官方文档说明，非文件字段有约 10MB 的保留空间；文件部分如果无法放入内存，会落到临时文件。

所以一个上传接口至少要区分：

如果只设置 maxMemory 而不限制请求体，攻击者仍可发送非常大的请求；如果只限制请求体而不清理 Form，临时文件则可能在高并发下积累。

在解析前限制请求总大小

上传接口通常先把请求体包装成 MaxBytesReader，再调用 ParseMultipartForm 或自行创建 multipart.Reader。下面的例子使用 Request.ParseMultipartForm，它内部会走 multipart 解析逻辑；关键是限制必须发生在读取表单之前。

package main

import (
	"errors"
	"fmt"
	"net/http"
	"mime/multipart"
)

func upload(w http.ResponseWriter, r *http.Request) {
	// 先限制整个请求体，避免异常大的上传进入完整解析阶段。
	const requestLimit = 32 

这个组合的重点是顺序：MaxBytesReader 保护网络读取，ParseMultipartForm 负责结构化解析，RemoveAll 负责清理副作用。不要把 requestLimit 误当成 memoryLimit；前者限制请求线上的总字节数，后者影响 multipart 解析时文件内容的内存与临时文件分配。

直接使用 Reader.ReadForm 时怎么设预算

如果已经从 Content-Type 里取得 boundary，也可以直接创建 multipart.Reader。这种写法适合需要显式掌握 Reader 生命周期的场景，但仍要在 Reader 的输入上设置请求上限，并在拿到 Form 后清理临时文件。

// 直接调用 ReadForm，并在业务处理完成后删除临时文件。
func parseForm(body io.Reader, boundary string) (*multipart.Form, error) {
	reader := multipart.NewReader(body, boundary)
	form, err := reader.ReadForm(8 

直接使用 ReadForm 时，调用方要额外记住：multipart.Form 可能持有临时文件路径，处理完所有 FileHeader 后必须调用 RemoveAll()。如果希望把清理责任限制在同一个函数内，可以把“打开、复制到业务存储、清理”放在同一个生命周期块中，避免把 Form 长时间塞进异步队列。

排查 ErrMessageTooLarge、临时文件和数量限制

遇到“内存占用仍然高”或“上传偶发失败”时，先按照现象分层排查。ErrMessageTooLarge 主要表示表单数据无法在允许的内存范围内处理，不能把它等同于所有上传超限；请求总大小超限可能由外层的 MaxBytesReader 返回读取错误。

还要注意标准库对 multipart 结构设有保护限制：当前文档说明，ReadForm 会限制表单部件数量为 1000，所有 FileHeader 的头部总数为 10000；这两个值可以通过 GODEBUG=multipartmaxparts 和 GODEBUG=multipartmaxheaders 调整。调整前要先确认是合法业务需求，而不是用全局参数掩盖异常输入。

落地时保留这份检查清单

一个可控的 Go multipart 上传处理器，至少应满足四点：第一，入口处限制请求总大小；第二，为 ReadForm 设定与业务文件规模匹配的内存预算；第三，文件处理完成后关闭句柄并调用 RemoveAll；第四，对字段长度、部件数、头部数和临时目录磁盘空间做独立监控。

如果业务只是接收单个大文件，不需要把全部字段解析成 Form，可以考虑按 NextPart 逐段读取，并对单个 Part 做更细的字节限制。ReadForm 更适合字段与文件一起处理的表单场景，关键不是追求一个“永不落盘”的参数，而是让内存、磁盘和请求大小各自有清晰边界。

ReadForm 的 maxMemory 设置为 0 就是不占内存吗？

不是。非文件字段仍有约 10MB 的保留空间，而且解析器本身还会产生必要的对象与缓冲。它表示文件内容的内存预算很小，不表示整个请求零内存。

文件落到临时目录后还需要自己删除吗？

需要。处理完 multipart.Form 后调用 RemoveAll()，否则临时文件的生命周期可能超过请求生命周期。发生错误时也要确保已经拿到的 Form 能进入清理路径。

只用 MaxBytesReader 能替代 ReadForm 的内存控制吗？

不能。它只限制请求总大小，不决定文件部分如何在内存和临时文件之间分配，也不负责清理 Form 产生的临时文件。上传接口通常需要两层限制同时存在。