Go multipart 上传文件的大小限制实现

Go 的 multipart 上传不要只给文件字段做一个大小判断。更稳妥的边界是：先用 http.MaxBytesReader 限制整个请求体，再用 ParseMultipartForm 控制文件 part 有多少字节留在内存，超限时统一返回 413 Request Entity Too Large，请求结束前关闭文件并清理临时目录。

官方文档入口（复制地址查看）：https://pkg.go.dev/net/http#MaxBytesReader。下面只讨论请求总大小、解析内存、临时文件和错误响应，不把文件类型校验或内容扫描混进这条链路。

为什么只检查 FileHeader.Size 还不够

上传请求的消耗不只有文件内容。multipart 边界、字段名、普通表单字段和多个文件的头部都会进入请求体；如果等解析完成后才查看 FileHeader.Size，解析过程已经先消耗了部分内存或磁盘空间。高并发时，单个请求看似不大，多个请求叠加也会让入口和临时目录承受压力。

因此可以把资源边界拆成三层：请求总上限负责阻止过大的输入继续被读取；解析内存预算负责决定哪些文件 part 留在内存；临时文件生命周期负责回收无法放进内存的内容。三层是配合关系，不是三个互相替代的文件大小判断。

先用 MaxBytesReader 卡住请求边界

MaxBytesReader 面向传入的 request body，和普通的 io.LimitReader 相比，它返回可关闭的 reader，超过限制时会返回 *http.MaxBytesError，并且会在可能时提示响应写入器关闭连接。这个上限应覆盖整个 multipart 请求，而不是只估算单个文件。

package upload

import (
    "errors"
    "io"
    "mime/multipart"
    "net/http"
    "os"
)

const (
    // maxRequestBytes 给整个 multipart 请求设置上限，要给边界和字段头部留余量。
    maxRequestBytes int64 = 20 

这里的两个数字含义不同：20 MiB 是完整 HTTP 请求的硬上限，2 MiB 是文件 part 的内存预算。文件稍大并不必然失败，因为 ParseMultipartForm 可以把超出内存预算的文件内容放到临时文件；真正超过 20 MiB 的请求才会从外层 reader 处失败。

把错误转换成稳定的 HTTP 响应

错误响应要根据失败位置区分。MaxBytesReader 触发时，解析器读取 body 会遇到 *http.MaxBytesError；而 multipart 自身在无法处理表单数据时可能返回 multipart.ErrMessageTooLarge。对调用方而言，两者都意味着“请求超过服务可接受的上传边界”，可以统一返回 413；Content-Type、boundary 损坏等普通格式问题则更适合返回 400。

不要调用 r.FormValue 来偷偷读取文件字段并忽略错误。官方文档说明，FormValue 会按需调用解析函数但忽略错误；上传入口需要知道解析是否越过了限制，所以应显式调用 ParseMultipartForm，再访问 FormFile。

临时文件不是泄漏，但不清理就会变成泄漏

ParseMultipartForm(maxMemory) 会解析整个请求；文件 part 超出内存预算后，标准库会把它们放到临时文件中。这个机制把峰值内存压了下来，却把责任转移到了磁盘空间、文件句柄和清理时机。只要处理函数已经成功解析，就可以在结束时调用 r.MultipartForm.RemoveAll()。

单个上传文件由 FormFile 打开后也要 Close。FileHeader 的文件可能来自内存，也可能来自磁盘，调用方不应假设具体实现；关闭动作应紧跟成功获取之后。保存到业务目录的目标文件则需要单独管理，失败时删除半成品，成功后再交给后续持久化流程。

清理顺序可以固定成一个小约定：解析成功后登记 RemoveAll，获取文件成功后登记 Close，创建业务目标成功后登记失败删除。这样无论后面是字段缺失、保存失败还是业务拒绝，都不会把资源回收依赖在某一条成功路径上。

文件更大或并发更高时改用 MultipartReader

当业务需要逐个处理 part、单独限制每个文件，或者不希望一次性构造完整的 MultipartForm，可以调用 r.MultipartReader() 按流读取。官方文档将它定义为处理 multipart body 的流式入口；不过流式解析不会替你取消请求总上限，外层的 MaxBytesReader 仍应保留。

func streamHandler(w http.ResponseWriter, r *http.Request) {
    // 流式入口同样先限制完整请求体，防止只控制单个 part 却放开总量。
    r.Body = http.MaxBytesReader(w, r.Body, 20

这段流式示例只展示入口和生命周期，不把丢弃数据当成业务保存方案。生产代码应在确认字段名后创建受控目标，写入时记录每个文件的字节数，并在写入失败时删除半成品。若只需要标准库自动管理内存与临时文件，前一个 ParseMultipartForm 版本更容易维护。

上线前按五个边界做取舍

如果上传网关、反向代理和 Go 服务各有一个限制，应把它们按“客户端可见的最小上限”对齐，并给 multipart 头部留出余量。高并发下还要为临时目录设置容量和监控；服务层的 413 只说明应用拒绝了请求，不等于磁盘和代理层自动获得了相同的保护。

结论与常见追问

一套可维护的 Go multipart 上传边界通常是：MaxBytesReader 限制请求总量，ParseMultipartForm 管理内存与临时文件取舍，显式识别超限错误并返回 413，最后用 Close 和 RemoveAll 完成资源回收。只有需要逐 part 控制和更细粒度流式处理时，才把入口换成 MultipartReader。

• maxMemory 越大越好吗？不是。它应结合并发量和可用内存设置，过大可能放大峰值。
• ParseMultipartForm 会限制请求总大小吗？它主要决定解析内存与临时文件分配，完整请求上限应由 MaxBytesReader 负责。
• 为什么客户端看到 400 而不是 413？通常是把 multipart 格式错误与请求超限混在同一分支，或在 FormValue 中提前忽略了解析错误。
• 流式读取还要清理临时文件吗？如果业务自行创建目标文件，就要按业务目标的成功、失败路径清理；流式入口不会自动替你管理这些目标。

官方资料（复制地址查看）：https://pkg.go.dev/net/http#MaxBytesReader、https://pkg.go.dev/net/http#Request.ParseMultipartForm、https://pkg.go.dev/mime/multipart#Reader。本文的上传处理器是基于标准库接口边界编写的原创示例，不声称已经运行或代表官方完整实现。