http.MaxBytesReader 超过限制后怎样识别请求体被截断

处理上传接口时，只设置一个请求体上限还不够，关键是要知道“读取完成”到底代表什么。使用 http.MaxBytesReader 包住 Request.Body 后，读到限制值以内的数据可以正常结束；一旦继续读取并越过上限，读取会返回 *http.MaxBytesError。因此，判断请求体是否被截断，应检查读取错误，而不是把所有非空错误都当成普通 EOF。

本文结论：在 Handler 入口限制 r.Body，读取后用 errors.As 识别 *http.MaxBytesError，再决定返回 413 或其它业务错误。不要仅依赖 Content-Length，因为分块传输或客户端声明不准确时，真正的边界仍然发生在读取阶段。

先分清 EOF、解析错误和超限

MaxBytesReader 面向服务端请求体，和 io.LimitReader 的定位不同：它返回的是 io.ReadCloser，超过限制时会返回带上限信息的 *http.MaxBytesError，关闭时还会关闭底层读取器。正常请求读完是 io.EOF 或由上层读取函数转换后的成功结果；格式错误则应保留原始解析错误。

在 Handler 入口限制请求体

限制应尽量靠近请求入口，这样后面的 JSON、表单或自定义解码器都不会直接接触未受限的原始 Body。下面示例把上限设为 1 MiB，并把读取错误留到统一分支判断。

package main

import (
	"errors"
	"io"
	"net/http"
)

func upload(w http.ResponseWriter, r *http.Request) {
	// 先包裹请求体，后续解码器只能读取到 1 MiB 以内的数据。
	const limit = 1 

这里的关键不是 io.ReadAll，而是它会持续读取直到结束或遇到错误；只有真正继续读取并越过限制，MaxBytesError 才有机会被观察到。若业务使用 JSON 解码器，也应保留同样的错误分层，不要只判断“解码失败”。

用 MaxBytesError 读出超限证据

MaxBytesError 的 Limit 字段能让日志或响应处理记录本次限制值。使用 errors.As 比直接类型断言更稳妥，因为中间层可能给错误增加上下文。

func classifyReadError(err error) int {
	var tooLarge *http.MaxBytesError
	if errors.As(err, &tooLarge) {
		// Limit 是本次限制值，可放入结构化日志字段。
		_ = tooLarge.Limit
		return http.StatusRequestEntityTooLarge
	}
	if errors.Is(err, io.EOF) {
		// EOF 表示读取自然结束，不代表请求体超限。
		return http.StatusNoContent
	}
	// 解析失败、连接中断等情况走普通坏请求分支。
	return http.StatusBadRequest
}

响应状态应在确认错误类型后再写出。若先写入成功响应，之后才发现请求体超限，就无法可靠地把状态改成 413；这也是把读取和响应决策放在同一错误分支中的原因。

四个容易误判的边界

• 刚好达到上限：达到限制值本身不等于超限，是否报错取决于后续读取是否还需要越过边界。
• 只看 Content-Length：它适合做提前判断，但不能替代读取阶段的错误识别。
• 忘记 Close：MaxBytesReader 的 Close 会关闭底层 Reader，Handler 仍应负责释放资源。
• 混淆限制位置：MaxBytesReader 限制的是传给它的请求体读取；网关、反向代理和 multipart 的内存策略仍是独立边界。

复查时可以按“入口是否包裹 Body、读取错误是否保留、是否用 errors.As、是否在写响应前完成判断”四项检查。这样既能挡住过大的请求，也不会把正常 EOF 或普通解析错误误报成请求体超限。

相关问题

MaxBytesReader 和 io.LimitReader 有什么区别？前者专门面向服务端请求体，返回 ReadCloser，并在超限时返回 MaxBytesError；后者只是通用的读取限制器。

一定要返回 413 吗？不一定。413 适合表达请求体超过服务端愿意处理的范围；如果接口协议有统一错误码，可以保留 MaxBytesError 作为内部判断，再映射到自己的响应格式。

官方地址：https://pkg.go.dev/net/http#MaxBytesReader