因为 Go 的 http.Request.ParseMultipartForm 默认内存限制为 32MB，超出即报“http: request body too large”错误。
为什么 ParseMultipartForm 会突然报 http: request body too large
因为 Go 的 http.Request.ParseMultipartForm 默认只给内存分配 32 （即 32MB），超出部分自动写入临时磁盘；但如果你没显式调用它，或调用前已读过 <code>Body（比如用了 io.ReadAll 或中间件提前消费），Go 就会在内部尝试解析时直接拒绝——此时错误不是“写磁盘失败”，而是硬拦截的 http: request body too large。
常见踩坑点：
- 在中间件里调用
io.ReadAll(r.Body)后，再调用r.ParseMultipartForm→ 必然失败（Body已关闭） - 设了
MaxMemory = 0→ Go 会跳过内存缓冲，全部走磁盘，但某些环境（如容器无写权限）导致tempfile创建失败，报错却仍是同一句 - 用
curl -F测试时没加-H "Content-Type: multipart/form-data; boundary=..."，实际发的是纯文本，Go 拒绝解析并返回 400，容易误判为内存问题
MaxMemory 设多大才合理：别只看单文件大小
MaxMemory 控制的是「整个 multipart 请求」在内存中能暂存的总字节数，不是单个 file 字段的上限。它包含所有文本字段值 + 所有文件字段的头部元信息 + 实际文件数据（直到阈值触发磁盘落盘）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 若业务确定只收小图（≤2MB）且最多 3 个文件 + 若干文本字段 →
MaxMemory = 10 （10MB）足够，避免频繁磁盘 IO - 若需支持单个 50MB 视频上传，且允许并发 10 路 → 内存峰值可能达 500MB，必须设
MaxMemory = 50 并确保 <code>runtime.GOMAXPROCS和系统 ulimit 不卡住 - 永远不要设
MaxMemory = -1或极大值（如1 ）→ Go 不校验溢出，超限后可能触发 OOM kill
正确设置 MaxMemory 的三步顺序不能错
顺序错了就白设：Go 要求在任何读取 Body 操作之前，先调用 ParseMultipartForm 并传入目标值。一旦 Body 被读、被复制、被解码（如 json.NewDecoder(r.Body)），ParseMultipartForm 就永久失效。
正确流程：
- 检查
r.MultipartForm == nil→ 确认尚未解析 - 立刻调用
r.ParseMultipartForm(20 （数值按需替换） - 之后再用
r.FormValue、r.FormFile或遍历r.MultipartForm.File
反例：用 httputil.DumpRequest 打印请求体 → 它会读 Body → 后续 ParseMultipartForm 直接 panic。
生产环境必须配合的两个关键配置
光调 MaxMemory 不够，HTTP 服务器本身和运行时环境会二次拦截：
-
http.Server.ReadTimeout和ReadHeaderTimeout要足够长——大文件上传耗时，超时会导致连接中断，错误日志里看不到 multipart 相关字样，只显示i/o timeout - Linux 容器内务必检查
/tmp可写且空间充足——当内存不足时，Go 用os.CreateTemp写临时文件，路径由os.TempDir()返回；若该目录不可写（如只读根文件系统），ParseMultipartForm会返回no space left on device或更隐蔽的permission denied
复杂点在于：这些限制层层嵌套，错误表现高度相似，得靠 strace 或日志里打印 err.Error() 全文才能区分是 Go 层、syscall 层还是容器层的问题。
