maxmultipartmemory设太小会直接导致parsemultipartform解析失败，formcache为空，c.postform始终返回空字符串，c.formfile返回nil和错误，上传流程中断。
MaxMultipartMemory设太小会导致什么？
它不是“影响性能”，而是直接阻断上传流程。设得太小（比如默认 32 即 32 MiB），一旦上传文件超过该值，<code>http: request body too large 错误会在 Gin 解析请求体的最早阶段触发——c.FormFile() 根本不会被调用，err 可能为 nil，但你连文件名都拿不到。
典型现象：
- 小图能传，100MB 视频上传失败，前端卡在 99%，后端日志只有模糊的 size error
-
c.PostForm("title")返回空字符串，因为 multipart 解析失败，formCache 没填充 - 错误信息里不带具体字段名或文件名，排查困难
怎么设才合理？
这个值不是越大越好，也不是越小越安全，它代表「Gin 在内存中缓存整个 multipart 请求体的最大字节数」。必须按业务预期最大单文件大小来设，且留出余量。
- 支持上传 50MB 视频 → 设为
r.MaxMultipartMemory = 50 （即 52,428,800） - 支持分片上传（每片 10MB）→ 设为
16 或 <code>32 足够，别盲目拉到 512MB - 绝对不要设为
0（不限制），否则恶意构造超大请求可耗尽服务内存 - 必须在
gin.Default()之后、任何路由注册之前设置，否则无效
为什么只调 MaxMultipartMemory 还是上传失败？
因为它只管「内存缓冲上限」，不管「传输时间」。大文件上传卡住，90% 是超时问题，和这个配置无关。
真正要同步改的是三层：
- Go
http.Server层：ReadTimeout: 10 * time.Minute（防止 TCP 连接被底层中断） - Nginx 层：
client_max_body_size 1g+proxy_read_timeout 600（否则请求根本到不了 Gin） - Gin 层：
r.MaxMultipartMemory仅用于避免http: request body too large，不是超时开关
漏掉任意一层，都可能表现为“前端进度条不动、后端无日志、c.FormFile 像没执行一样”。
什么时候不该用 FormFile？
当你要处理超大文件（如 >200MB）、或需要流式校验（如检查 magic bytes）、或想避免内存峰值时，c.FormFile() 就不合适了——它会把整个文件内容读进内存再返回 *multipart.FileHeader。
正确做法是绕过它，用原始 reader：
- 先设
r.MaxMultipartMemory = 32 （够解析表单头即可） - 调
reader, err := c.MultipartReader() - 用
reader.NextPart()遍历每个 part，对文件 part 手动io.Copy到磁盘临时文件 - 这样内存占用恒定，不随文件大小增长
这个路径下，c.FormFile 和 c.PostForm 都不再可用，所有字段都要手动解析，但换来的是可控性和稳定性。
