请求体上限

服务端的“请求体上限”不是把 Content-Length 读出来比较一下，而是要在任何 JSON、表单或文件解析之前限制 r.Body。Go 标准库提供的直接做法是 http.MaxBytesReader：它包装一个可关闭的请求体，读取超过上限时返回 *http.MaxBytesError。这样即使客户端没有提供可靠的长度，处理器也不会无界地把数据交给 io.ReadAll。

先限制，再解析；超限返回 413，普通读取失败仍按 400 或 500 的业务规则处理。上限应按接口用途单独设定，而不是给所有接口一个巨大的公共值。

一、先看无界读取为什么会拖慢接口

常见处理器会直接调用 io.ReadAll(r.Body)，再把字节交给 JSON 解码器。问题在于 io.ReadAll 的语义是持续读取直到 EOF；请求体越大，内存占用、复制次数和处理时间就越不可控。即使客户端带了 Content-Length，分块传输或错误长度也会让“只比较请求头”变成不完整的防线。

我们先把观察口径固定为三组请求：正常体积不超过上限、刚好超过上限、没有可信长度但持续发送。重点记录响应状态、处理器读到的错误类型和峰值内存，而不是只看接口平均耗时。

二、把 MaxBytesReader 放在解析之前

下面的处理器只接受不超过 1 MiB 的 JSON。关键顺序是先替换 r.Body，再调用 json.Decoder；defer 负责关闭包装后的读取器，错误分支则把超限和其他坏请求分开。

package main

import (
	"encoding/json"
	"errors"
	"net/http"
)

type createRequest struct {
	Name string `json:"name"`
}

func createHandler(w http.ResponseWriter, r *http.Request) {
	const maxBody = 1 

这里没有手写一个普通的 io.LimitReader 来替代它。两者都能限制读取量，但 MaxBytesReader 返回 ReadCloser，超限时给出可识别的 *http.MaxBytesError，并且专门面向服务端传入请求体。

三、超限判断要看读取错误，不要只看请求头

当客户端提前发送了一个很大的请求体，真正触发限制的时刻通常发生在解析器继续读取时。因此判断点应放在解码或读取返回的 err 上。使用 errors.As 比直接比较错误字符串稳妥，因为它关注错误类型和链，而不是把文案写死。

如果接口还要支持更大的上传文件，应该给上传接口单独设计上限和落盘策略，不能因为某个接口需要大文件就把全站 JSON 请求体上限一起调大。反过来，若请求体上限较小，错误响应也要保持短小，避免在失败分支再次读取或回显完整请求内容。

四、用固定口径确认限制确实生效

可以用 512 KiB、1 MiB、1 MiB+1 字节三档请求做最小观察集，并分别记录状态码和错误分类。预期结果是：前两档在上限内正常进入业务；超过上限的请求返回 413；无 Content-Length 的持续输入同样在读取层被截断。这个观察能证明限制依赖的是读取行为，而不是单一请求头。

最后再检查一个容易遗漏的顺序：如果中间件已经读取过 r.Body，后面的处理器再包裹上限就晚了。请求体限制应尽量靠近入口，并在所有会读取正文的中间件之前完成。

相关问题

Content-Length 小于上限还需要 MaxBytesReader 吗？

需要。它可以帮助提前拒绝明显超限的请求，但不能覆盖没有可信长度或分块传输的情况。

为什么不能把超限错误当成普通 JSON 语法错误？

两者的修复动作不同：语法错误通常提示调用方修正格式，超限则提示调用方缩小正文或使用专门的上传接口。