根本原因是c.FormFile触发的multipart解析默认将整个请求体读入内存，受MaxMultipartMemory控制；100MB文件直接分配100MB内存导致GC压力陡增、goroutine阻塞在I/O等待。
为什么 c.FormFile 调用后大文件上传仍卡顿？
根本原因不是 c.FormFile 本身慢，而是它触发的 multipart 解析默认把整个请求体读进内存（受 MaxMultipartMemory 控制）。100MB 文件一上来就分配 100MB 内存，GC 压力陡增，goroutine 阻塞在 I/O 等待上。
- 默认
MaxMultipartMemory是 32MB，超限会自动 fallback 到临时磁盘文件，但路径不可控、无清理机制 - 未显式设置超时，
ReadTimeout/WriteTimeout缺失时，慢客户端可能让连接长期 hang 住 - 前端未分块或未加
enctype="multipart/form-data"，导致后端根本收不到 multipart body
c.FormFile 后必须手动流式处理，不能用 c.SaveUploadedFile
c.SaveUploadedFile 是 convenience wrapper，但它强制一次性读取全部内容到内存再写入磁盘，完全绕过流控能力。真正可控的路径是：打开 *multipart.FileHeader → 校验 → 流式复制 → 关闭。
- 用
file.Open()获取io.ReadCloser，而非直接调用SaveUploadedFile - 校验逻辑必须放在
src.Read()之前：size、MIME、magic bytes（如image/jpeg头 4 字节是否为FF D8 FF） - 写入时用
io.CopyN(dst, src, limit)或带 buffer 的io.Copy，避免单次 read 过大（如 64KB）
HTTP 层和 OS 层的 IO 调优关键配置
Gin 自身不管理底层 socket 和文件描述符，性能瓶颈常卡在 net/http Server 和 OS 设置上。
- 启动 server 时显式配置：
ReadTimeout: 30 * time.Second、WriteTimeout: 120 * time.Second（大文件需更长写超时） - 调大
http.Server.MaxHeaderBytes（默认 1MB），避免含大量字段的表单被截断 - Linux 下调整：
net.core.somaxconn（连接队列）、fs.file-max（文件句柄上限）、vm.swappiness=1（减少 swap 干扰） - Gin 路由 handler 内不要做阻塞 I/O（如同步写磁盘），应交由 goroutine + channel 异步落盘
上传路径遍历和并发安全怎么防？
前端传 ../../etc/passwd 这类文件名，c.FormFile("file").Filename 会原样返回，不做任何过滤 —— 这是 Gin 的设计选择，不是 bug。
- 必须手动 sanitize：
filepath.Base(file.Filename)只取末尾文件名，丢弃所有路径信息 - 目标目录（如
"./uploads/"）要提前os.MkdirAll，且检查权限：os.Stat+os.IsNotExist - 高并发下多个请求同时写同一文件名？用
os.O_CREATE | os.O_EXCL | os.O_WRONLY打开，失败即重试或返回冲突 - 别用全局
sync.Pool缓存bytes.Buffer来读 multipart body —— 它不支持io.Reader接口复用，反而引入竞态
实际生产中，最易被忽略的是：MaxMultipartMemory 和 WriteTimeout 必须成对调大，且前者不能大于后者能容纳的数据量。比如设了 120s 超时，但网络只有 1MB/s，那 MaxMultipartMemory 最多只能设 120MB，否则必然 OOM。
