大文件上传卡在超时并非代码错误，而是连接被nginx、go http.server或浏览器提前中断；需同步调整三层超时：go层设http.server.readtimeout、gin层调r.maxmultipartmemory、nginx层配proxy_read_timeout及client_max_body_size。
为什么大文件上传总卡在超时？
不是代码写错了，而是 HTTP 请求还没传完，连接就被中间件或 Go 自身断开了。Gin 默认不设读取超时，但反向代理（如 Nginx）、Go 的 http.Server、甚至客户端浏览器都可能提前切断连接。常见现象是前端进度条走到 90% 就停住，后端日志里没报错，c.FormFile 根本没被调用——请求压根没进 handler。
必须同步调整三层超时配置
只改 Gin 的 MaxMultipartMemory 不解决超时问题，它只控制内存上限，不控制时间。真正要动的是这三处：
-
Go HTTP Server 层：启动时显式设置
ReadTimeout，例如http.Server{ReadTimeout: 10 * time.Minute}；别依赖默认值（Go 1.26+ 默认为 0，但实际受底层 TCP keepalive 影响） -
Gin 引擎层：调用
r.MaxMultipartMemory = 256 （256MB），避免因内存限制触发 <code>http: request body too large错误，该错误常被误判为超时 -
反向代理层（如 Nginx）：必须同步改
client_max_body_size（比如1g）和proxy_read_timeout（比如600），否则请求在到达 Gin 前就被 Nginx 拒绝或中断
c.FormFile 调用时机决定是否真能收到文件
很多人把超时归咎于 c.FormFile 执行慢，其实它本身不耗时——它只是触发 multipart 解析的开关。关键点在于：
-
c.FormFile("file")是首次调用才解析整个 body，后续同名字段调用返回nil和错误；所以不能靠多次调用“试探”文件是否存在 - 如果前端用了
FormData.append("avatar", file)，后端必须用c.FormFile("avatar")，名字错一个字符就拿不到，且不会报错，只会返回空file == nil - 一旦 multipart body 开始解析，就占用连接；若此时超时已到，Go 会直接关闭连接，导致
c.FormFile返回http: request body closed类错误
上传中断后无法续传？那得换分片方案
单次上传再怎么调超时，也扛不住网络抖动。真要可靠，就得放弃 c.FormFile 这套原生 multipart 流程，改用分片上传：
- 前端按固定大小（如 5MB）切块，每块带
uploadId和chunkIndex参数单独 POST - 后端每个分片用
c.Request.MultipartReader()或直接读c.Request.Body，避免触发 Gin 自动解析（可禁用MaxMultipartMemory或设为 0） - 服务端记录每个
uploadId已收分片，合并前校验 MD5 或 size 总和，防止拼接错位
分片上传的难点不在传输，而在状态管理——uploadId 生命周期、分片去重、磁盘临时文件清理，这些比调超时参数容易被忽略得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
