multipart 表单读取时报 message too large 怎么处理

Go 里遇到 multipart: message too large，先不要只把 ParseMultipartForm 的参数改大。这个错误通常说明非文件字段无法放进 ReadForm 的内存预算；如果是整个 HTTP 请求超过上限，则更接近 http.MaxBytesError。普通表单可以提高内存预算并保留请求体上限，超大文件则应改用 MultipartReader 逐个 Part 流式处理。

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

最稳妥的处理方式是先区分“请求总量超限”和“非文件字段内存不足”：前者收紧或调整请求体策略，后者调整解析预算；如果消息本来就很大，直接切换到流式读取。

先分清是请求体过大还是 ReadForm 内存预算不足

multipart.Reader.ReadForm 解析整个表单，并允许文件部分在内存不足时写入临时文件，但非文件字段不能无限增长。当这些字段无法满足内存预算时，返回的就是 multipart.ErrMessageTooLarge。这和客户端上传一个大文件并不是同一件事：大文件可能只是落盘，过多的大文本字段才会先触发这个错误。

HTTP 层还可以用 http.MaxBytesReader 限制整个请求体。它保护的是入口资源；超过该值时，错误通常可以通过 errors.As 识别为 *http.MaxBytesError。这两个限制应该同时存在：一个防止总请求失控，一个约束表单解析时的内存预算。

普通表单用总量上限加错误分类

如果表单只有少量字段和小文件，可以保留一次性解析，但要把入口限制、解析预算和临时文件清理写在同一个处理函数里。下面的示例把请求总量设为 32 MiB，把解析时的内存预算设为 8 MiB；数值只是一个有边界的起点，应按业务字段和文件大小调整。

func upload(w http.ResponseWriter, r *http.Request) {
	const maxBody = 32 

这段代码的关键不是“把 8 MiB 改成更大的数字”，而是让客户端得到不同的错误语义。若只处理 ErrMessageTooLarge，请求体总量限制触发时仍可能被归类成普通表单错误；若只使用 FormValue，又容易把真实解析错误吞掉，因为它会忽略 ParseMultipartForm 返回的错误。

超大文件改用 MultipartReader 流式读取

当文件可能达到几十 MiB、几百 MiB，或者字段数量不稳定时，不应把整个消息交给 ParseMultipartForm。Request.MultipartReader 返回按消息边界读取的 reader；每次拿到一个 Part，就能分别处理字段和文件，并在复制时加上单 Part 的上限。

func streamUpload(w http.ResponseWriter, r *http.Request) {
	const maxBody = 128 

示例中的 io.LimitReader 只负责让读取不超过预算；生产代码还应记录实际字节数，读取“上限加 1”来判断是否真的超限，并在失败时删除未完成的临时目标。请求级上限、字段上限、单文件上限三者的关系应明确，不能只依赖其中一个。

排障时别漏掉这几个边界

• 不要只调参数：如果反向代理、网关或框架前置层已经拒绝大请求，Go handler 根本收不到消息。
• 不要重复解析：ParseMultipartForm 第一次调用后，后续调用不会重新读取 body；要在第一次解析处保留错误。
• 记得清理：使用一次性解析时调用 MultipartForm.RemoveAll，流式方案则由业务负责临时文件的成功转存或失败删除。

如果只是小表单，选择“MaxBytesReader + ParseMultipartForm + 错误分类”最简单；如果文件大小或字段数量不可预测，直接使用 MultipartReader，把资源上限下沉到每个 Part，通常更容易控制内存和磁盘。

相关问题

把 ParseMultipartForm 的 maxMemory 调大就一定能解决吗？

不一定。它只改变解析阶段的内存预算，不能取消请求体总量限制，也不能防止大量并发请求同时占用内存。先确认错误类型和入口容量，再决定是否调整。

为什么大文件没有触发 ErrMessageTooLarge？

文件 Part 可以在超过内存预算后写入临时文件，而非文件字段需要留在表单结构中。只有请求总量或非文件字段触碰对应限制时，才会出现不同的超限错误。