go标准库http.server无maxrequestbodysize字段是设计取舍，因服务层不解析请求体，需在handler中用http.maxbytesreader主动限制，否则易引发oom；须显式检查http.errbodytoolarge错误。
为什么 http.Server.MaxRequestBodySize 不存在
Go 标准库的 http.Server 结构体确实没有 MaxRequestBodySize 字段——这不是遗漏，而是设计取舍。HTTP 服务层不直接解析请求体，它把原始字节流交给 handler 处理，因此大小限制必须由你主动介入，否则可能被恶意大请求耗尽内存或触发 OOM。
在 handler 中用 http.MaxBytesReader 控制读取上限
最常用、最可靠的方式是用 http.MaxBytesReader 包装 req.Body。它不是拦截或拒绝请求，而是在读取时动态抛出 http.ErrBodyTooLarge 错误（注意：这个错误类型需显式判断）。
常见错误现象：io: read/write on closed pipe 或静默截断，往往是因为没检查 MaxBytesReader 返回的错误，或者在解码 JSON 前没提前校验。
实操建议：
- 始终在 handler 开头就包装
req.Body，例如：req.Body = http.MaxBytesReader(w, req.Body, 10（限制 10MB） - 后续调用
json.NewDecoder(req.Body).Decode()等操作时，必须检查返回的 error 是否为http.ErrBodyTooLarge - 不要在包装后还对原
req.Body做任何读取，否则会跳过限制逻辑 - 如果 handler 中需要多次读 body（如日志 + 解析），得先用
io.ReadAll拷贝到内存或临时文件，并确保该拷贝也受MaxBytesReader保护
配合中间件统一处理 http.ErrBodyTooLarge
手动每个 handler 都检查 http.ErrBodyTooLarge 容易漏，更适合抽成中间件。但要注意：标准 http.Handler 接口不暴露错误类型，所以中间件只能包裹 handler 函数本身，在调用后检查 panic 或返回值错误 —— 而 Go HTTP handler 的 error 是通过 http.Error 或写响应体现的，不能靠返回值捕获。
实操建议：
- 推荐在 handler 内部统一用类似
if errors.Is(err, http.ErrBodyTooLarge) { http.Error(w, "request too large", http.StatusRequestEntityTooLarge); return } - 若用 Gin/echo 等框架，它们封装了
MaxMultipartMemory和MaxBytesReader集成，但底层仍依赖相同机制，务必确认你调用的是框架提供的读取方法（如c.ShouldBindJSON()），而非绕过直接读c.Request.Body - 不要试图在
http.Server.ReadTimeout或WriteTimeout上做文章——它们控制连接生命周期，和请求体大小无关
multipart 表单要额外设 maxMemory 和临时目录
当请求含 multipart/form-data，Go 会自动调用 ParseMultipartForm，它内部使用内存缓冲 + 临时磁盘存储。此时仅靠 MaxBytesReader 不够：因为 ParseMultipartForm 会先尝试把所有 part 加载进内存，超出 maxMemory 才落盘。若不限制，小内存机器可能瞬间被多个并发上传打满。
实操建议：
- 显式调用
req.ParseMultipartForm(32 （32MB 内存上限），而不是依赖默认的 32MB；若设为 0，则全部落盘，但 I/O 开销上升 - 设置
req.MultipartForm.File中的文件临时路径前，确保目标目录可写且有空间，否则会静默失败或 panic -
MaxBytesReader应放在ParseMultipartForm之前，否则 multipart 解析器可能已读取部分 body，导致限制失效
