http.Server 默认不限制请求体大小，实际400错误主因是未用http.MaxBytesReader手动包装r.Body、反向代理截断或超时；需在handler中调用http.MaxBytesReader并返回413。
为什么 http.Server 默认会拒绝大请求体
Go 标准库的 http.Server 默认对请求体大小没有硬性限制，但实际中常遇到 400 错误或连接被关闭，根本原因通常是：http.MaxBytesReader 未显式设置、反向代理（如 Nginx）截断、或客户端超时触发。真正起作用的是 http.MaxBytesReader —— 它不是自动启用的，必须手动包装 Request.Body 才生效。
如何用 http.MaxBytesReader 限制单个请求体大小
在 handler 中主动限制，是最直接可控的方式。注意它只限制读取字节数，不改变 HTTP 状态码逻辑，需自行返回 413。
- 用法：把原始
r.Body包一层http.MaxBytesReader(r, r.Body, max)，max单位是字节 - 推荐放在 handler 开头，避免后续逻辑（如
json.NewDecoder）意外读超限 - 错误处理要检查
io.ErrUnexpectedEOF或http.ErrBodyReadAfterClose，但更常见的是io.ReadFull类错误或解码失败
func uploadHandler(w http.ResponseWriter, r *http.Request) {
const maxUpload = 10 << 20 // 10MB
r.Body = http.MaxBytesReader(w, r.Body, maxUpload)
defer r.Body.Close()
if err := r.ParseMultipartForm(maxUpload); err != nil {
http.Error(w, "request too large", http.StatusRequestEntityTooLarge)
return
}
// ...
}
全局设置 http.Server.ReadTimeout 和 MaxHeaderBytes 的影响
这些参数不直接限制请求体，但会影响大请求的存活窗口和头部解析阶段。忽略它们会导致看似“体大被拒”，实则是超时或 header 溢出。
-
ReadTimeout控制从连接建立到读完所有 header + body 的总时间，上传大文件时务必调大（如 300 秒） -
MaxHeaderBytes默认 1MB，若带大量自定义 header（如 JWT、base64 元数据），可能在此阶段就 400 -
IdleTimeout和ReadHeaderTimeout也需同步调整，否则长连接在上传中途被断开
Nginx 或其他反向代理带来的隐性限制
Go 服务跑在 Nginx 后面时，client_max_body_size（Nginx）、proxy_buffering、proxy_buffer_size 都会先于 Go 层拦截请求。常见现象是 Go 日志里完全收不到请求，curl 却报 413 或 Connection reset。
立即学习“go语言免费学习笔记（深入）”；
- 确认 Nginx 配置含
client_max_body_size 20M;（值应 ≥ Go 层设置） - 禁用
proxy_buffering off;可避免大 body 被缓存再转发，减少内存压力和延迟 - 如果用
proxy_pass https://...，还要检查后端 TLS 握手和 early data 限制是否干扰流式上传
真正麻烦的从来不是 Go 本身——而是限制层层叠加又没暴露明确错误来源。调试时优先抓包看 TCP RST 发生在哪一层，再逐段关掉代理/超时/读限制做隔离验证。
