Go multipart.Reader限制 multipart 上传总大小的实现方法

我在处理 multipart 上传时最容易犯的错，是看到 multipart.Reader 就想找一个“最大字节数”参数。实际上，Reader 负责按 boundary 解析 Part，并没有直接的整包大小开关；ReadForm(maxMemory) 也主要描述内存与临时文件策略。稳妥做法是把总请求体上限放在 HTTP Body 外层，再对单个文件 Part 设置局部预算。

先分清三种大小边界，再决定限制放在哪里

这个问题最好按责任拆开。请求体总上限回答“这一次 HTTP 上传最多允许读多少字节”；单个 Part 上限回答“某个文件字段最多能落多少字节”；ReadForm(maxMemory)回答“表单解析时多少内容优先留在内存，超出后如何使用临时文件”。三者的对象不同，混用后就会出现大文件仍能持续读取，或小文件被错误拒绝的情况。

用请求体预算兜住总量，再给文件 Part 加局部上限

在 Handler 里先限制 r.Body，然后再创建 Reader。下面的示例把整包上限设为 32 MiB，并把单个文件上限设为 8 MiB；代码中的注释说明了两个预算为什么不能合并。

var ErrUploadTooLarge = errors.New("upload exceeds size limit") // 中文注释：统一表示业务层的上传大小拒绝。

const (
    maxUpload = 32  maxFile {
            http.Error(w, ErrUploadTooLarge.Error(), http.StatusRequestEntityTooLarge)
            return
        }
    }
    w.WriteHeader(http.StatusNoContent)
}

这里的 maxFile+1 是有意的：只读到 8 MiB 时无法判断后面是否还有第 8 MiB+1 个字节，多读一个字节才能把“刚好达到上限”和“确实超限”分开。生产代码还应在读取真实文件前先校验字段名、文件名和内容类型。

超限处理要区分总量、单文件和解析错误

如果总请求体超过 maxUpload，错误可能在 NextPart、Part 的 Read 或 io.Copy 阶段才暴露，因为 Reader 是按需消费输入的。不要只在进入 Handler 时检查 Content-Length：没有这个头，或者使用分块传输时，仍然要依赖受限 Body。与此同时，单文件超限属于业务拒绝，和 multipart 格式损坏不是同一个 HTTP 响应。

若改用 ReadForm，读取完成后要在不再需要表单时调用 form.RemoveAll()，清理可能产生的临时文件。想限制整个请求时，不能只把 maxMemory 调小；它并不替代请求体预算。

我会保留的检查清单

上线前我通常只确认四件事：入口是否设置总请求体上限；单文件规则是否独立于总量规则；超限错误是否能定位到总量或当前 Part；使用 ReadForm 时临时文件是否有清理路径。若还接了反向代理，代理层可以有更早的限制，但应用层仍应保留自己的 Body 预算，避免内部调用绕过入口规则。

常见问题

只设置 Content-Length 大小检查够不够？

不够。它只能提前拦截带有可信长度声明的请求，不能覆盖分块传输或声明不准确的情况；读取链路仍需要 http.MaxBytesReader。

ReadForm 的 maxMemory 能限制上传总大小吗？

不能把它当作总大小开关。它主要影响表单解析时的内存使用与文件落盘，整包上传上限应放在请求体外层。

为什么单个 Part 要多读一个字节？

因为只读到上限值时还不能证明没有第一个超限字节。用上限加一的预算读取，才能把“刚好达到”与“超过限制”区分开。