Go net/http MaxBytesError 怎样识别请求体超限

我们在写Go HTTP服务做请求体大小限制的时候，用标准库net/http提供的能力就能快速识别出请求体超出预设上限的场景，不需要自己手动做字节计数判断，只要对读取请求体返回的error做类型断言就可以拿到对应的`MaxBytesError`实例。

你可以把读取请求体得到的error直接断言为`http.MaxBytesError`类型，如果断言结果为真，就代表本次请求体大小触发了上限限制，同时还能直接从实例里拿到实际超限前读取的字节数。

在 Go HTTP 服务里，最稳妥的做法是先把 r.Body 交给 http.MaxBytesReader，再开始 JSON、表单或 multipart 解析。读取超过上限时，返回的错误可以通过 errors.As 识别为 *http.MaxBytesError，此时返回 413；如果是连接中断、格式错误等普通读取失败，则保留原来的错误处理分支。

关键点不在于记住一条错误文本，而在于保留错误类型。MaxBytesError.Limit 还能告诉日志或响应策略当前限制值是多少。

先把请求体限制放在解析之前

MaxBytesReader 的职责是包装一个 io.ReadCloser，让后续读取不能无限消耗请求体。它和 io.LimitReader 的区别是：前者面向 HTTP 请求体，返回仍然是可关闭的读取器，超限时还会返回 *http.MaxBytesError。

func upload(w http.ResponseWriter, r *http.Request) {
	// 先限制整个请求体，再让后续解析器读取包装后的 Body。
	const maxBody = 2 

包装位置要早于 json.Decoder.Decode、ParseMultipartForm 或其他会读取 Body 的调用。若先解析再包装，已经被消费的字节不会重新受到限制；只检查 Content-Length 也不够，因为请求可能使用分块传输。

用 errors.As 识别 MaxBytesError

读取错误可能经过业务层包装，所以不要写成 err.Error() == "http: request body too large"。使用 errors.As 可以沿错误链查找目标类型，既能识别 MaxBytesReader 产生的错误，也不会误伤其他读取失败。

func writeReadError(w http.ResponseWriter, err error, limit int64) {
	var tooLarge *http.MaxBytesError
	if errors.As(err, &tooLarge) {
		// Limit 来自包装器，响应只给客户端稳定的错误类别。
		log.Printf("request body exceeds limit=%d: %v", tooLarge.Limit, err)
		http.Error(w, "request body is too large", http.StatusRequestEntityTooLarge)
		return
	}

	if errors.Is(err, io.EOF) {
		// 空请求体或提前结束的输入，不要伪装成大小超限。
		http.Error(w, "request body is empty", http.StatusBadRequest)
		return
	}

	// 连接中断、底层 I/O 失败等走独立的内部错误分支。
	log.Printf("read request body failed: %v", err)
	http.Error(w, "cannot read request body", http.StatusBadRequest)
}

代码中的 limit 参数用于表达调用方配置，但真正的上限以 tooLarge.Limit 为准。正式服务通常只把“请求体过大”告诉客户端，不把内部错误链或实现细节回传出去。

把超限、普通错误和正常结束分开

一个实用的处理顺序是：先判断目标类型，再判断业务需要的 EOF 或格式错误，最后处理无法归类的读取失败。超限返回 413（http.StatusRequestEntityTooLarge），普通输入错误一般返回 400；不要因为两者都发生在 Read 阶段，就把它们写进同一条日志或同一个响应。

如果使用 multipart，限制值作用于被包装的整个请求体，不只是某个文件字段。边界串、普通字段和文件内容都会占用额度，因此“文件大小刚好等于限制”不代表整个请求一定能通过。

发布前最容易漏掉的检查点

我在接入这类限制时，最容易漏的是包装顺序和关闭责任：先确认所有解析入口都读取包装后的 r.Body，再确认 handler 或框架会关闭它。不要只依赖客户端声明的长度，也不要通过字符串匹配判断超限，更不要把 MaxBytesError 当成 JSON 格式错误。

• 限制发生在所有 Body 读取之前。
• 用 errors.As 判断 *http.MaxBytesError。
• 日志记录 Limit，响应只暴露稳定类别。
• multipart 场景按整个请求体预算，而不是只按文件预算。
• 保留 Close，并为普通 I/O 错误保留独立分支。

相关问题

MaxBytesReader 和 io.LimitReader 应该怎么选？

如果要限制 HTTP 请求体，优先用 MaxBytesReader，因为它保留关闭能力并提供专用错误类型；普通流读取才考虑 io.LimitReader。

为什么不能只判断 Content-Length？

请求可能没有可靠的长度头，也可能使用分块传输。真正的读取上限必须放在 Body 的读取链上。

超过限制后应该返回什么状态码？

通常返回 413，即 http.StatusRequestEntityTooLarge，并避免把内部错误文本直接暴露给客户端。