只改r.maxmultipartmemory无效，因该参数仅控制内存上限而不影响超时；真正中断连接的是nginx（需配client_max_body_size和proxy_read_timeout）或go的http.server（需显式设readtimeout），请求未完整到达gin层，c.formfile根本不会被触发。
为什么只改 r.MaxMultipartMemory 没用
很多人一看到 http: request body too large 就猛调 r.MaxMultipartMemory，结果前端进度条卡在 95%、后端日志静默、c.FormFile 根本没被触发——问题不在 Gin 解析层，而在于请求压根没完整到达 Gin。Gin 只负责解析 multipart，不负责“等你传完”。真正掐断连接的是 Nginx 或 Go 的 HTTP Server。
Nginx 层必须配的两项
如果你用 Nginx 做反向代理（绝大多数生产部署都如此），以下两个配置缺一不可：
-
client_max_body_size 2g;—— 必须大于你要支持的最大单文件体积，单位可写2g、2048m，不能只写数字 -
proxy_read_timeout 1200;—— 这个值要 ≥ Go 层ReadTimeout，且必须放在location块里（不是http或server全局），否则对 proxy 请求不生效
错误示例：proxy_read_timeout 写在 server 块顶层，或漏掉 location /api { ... } 的显式包裹，会导致超时仍为默认 60 秒。
Go HTTP Server 层的 ReadTimeout 怎么设
Gin 本身不管理连接生命周期，它跑在标准 http.Server 上。启动时必须显式传入超时配置：
r := gin.Default()
srv := &http.Server{
Addr: ":8080",
Handler: r,
ReadTimeout: 10 * time.Minute, // 关键：控制从 TCP 连接建立到请求头+body读完的总时间
WriteTimeout: 10 * time.Minute,
}
log.Fatal(srv.ListenAndServe())
注意：ReadTimeout 不是“上传耗时”，而是“整个请求读取完成时限”。如果用户网速慢、中间有 NAT 或代理，这个时间必须留足。Go 1.26+ 虽然默认 ReadTimeout = 0（即不限），但底层 TCP keepalive 仍可能在 2–5 分钟内断连，所以显式设置更可靠。
c.FormFile 调用时机决定你能否拿到文件
这个函数不是“读文件”，而是“触发 multipart 解析”的开关。它的行为直接影响超时表现：
- 首次调用
c.FormFile("xxx")才开始解析整个请求 body；在此之前，连接处于空闲等待状态，超时计时器持续走 - 如果此时超时已到，Go 直接关闭连接，后续再调
c.FormFile会返回http: request body closed - 字段名必须和前端
FormData.append("file", blob)或<input name="file">完全一致，大小写敏感，拼错就收不到，且无报错提示
真正容易被忽略的是：上传中断后，你无法靠重试 c.FormFile 恢复。一旦连接关闭，请求上下文就销毁了。要可靠上传，得放弃单次 multipart，改用分片 + 独立签名校验的方案。
