Go http.MaxBytesReader 如何限制上传体大小

做 Go 上传接口时，最稳妥的总量限制不是只看 Content-Length，而是在 Handler 入口把 r.Body 替换成 http.MaxBytesReader。后续无论是 io.ReadAll、JSON 解码还是 multipart 解析，读到上限之外都会得到可识别的 *http.MaxBytesError，服务端可以统一返回 HTTP 413。

把 r.Body 交给 http.MaxBytesReader 后，上传读取就有了统一上限；超限时识别 *http.MaxBytesError，再把它映射为 413，不必在每个解析器里重复计算字节数。

先把限制放在 Handler 的入口

我通常把上传限制放在路由处理函数的第一段。这样做的价值在于，后面的解析代码不必各自记住上限；只要它们通过 r.Body 读取，就共享同一个边界。下面的例子把上限设为 8 MiB，正常内容返回 200，超过上限则返回 413。

const maxUpload = 8 

MaxBytesReader 返回的仍是 io.ReadCloser，所以可以直接替换 r.Body。错误类型里有 Limit 字段，日志若要记录限制值可以读取它；对客户端则建议固定返回简短的 413，不把内部细节暴露出去。

读取方式不同，超限判断仍在同一层

如果接口接收 JSON，可以把受限后的 Body 交给 json.Decoder；如果接收文件，则先限制 Body，再调用 ParseMultipartForm。关键顺序只有一个：解析器不能先拿到原始 r.Body。

func jsonHandler(w http.ResponseWriter, r *http.Request) {
    r.Body = http.MaxBytesReader(w, r.Body, 1

这层分类很重要：网络断开、格式错误和大小超限的处理动作不同。Go 官方实现还会让超限错误保持稳定，后续再次读取仍得到同一个错误；不要用错误字符串模糊判断，优先使用 errors.As。

Content-Length 只能做预检查

请求带有 Content-Length 时，可以在读取前快速拒绝明显过大的请求，减少无谓工作。但它不是最终防线：请求可能使用分块传输，也可能经过代理改写。因此预检查通过后，仍要用 MaxBytesReader 包住 Body。

上线前检查这几个边界

上限应按业务文件类型拆分，例如头像、附件和批量导入不一定共用一个数字。若前面还有 Nginx、网关或对象存储，也要确认它们的限制值和错误响应不会互相矛盾。应用层 413 负责保护 Go Handler，代理层限制负责尽早丢弃流量，二者是分层关系。

还要留意读取顺序：不要在包住 Body 之前调用 ParseForm、ParseMultipartForm 或自定义的 io.ReadAll。已经被读取的内容无法再用新的 Reader 追回。最后保留 defer r.Body.Close()，并在日志中记录接口名、限制值和错误类型，而不是完整上传内容。

常见问题

只判断 Content-Length 能不能限制上传大小？

不能。它只能处理请求声明了长度的情况，实际读取仍应经过 MaxBytesReader。

超过限制一定会返回 413 吗？

应用可以把 *http.MaxBytesError 映射为 413，但代理层可能先返回自己的错误页，所以应统一链路上的状态码和提示。

multipart 的 maxMemory 设小一点就够了吗？

不够。它主要决定解析时多少内容留在内存，超出的部分可能进入临时文件；总请求体仍需由 MaxBytesReader 限制。

相关资料：Go net/http MaxBytesReader 文档、Go 官方 request.go 源码。