c.MultipartForm()不能直接用于高并发上传，因其是同步阻塞调用，一次性读取整个请求体到内存，且不涉及并发；真正并行需客户端多请求或服务端手动goroutine分发，但须控制并发数、校验文件名与类型、避免资源耗尽。
为什么 c.MultipartForm() 不能直接用于高并发上传
很多人误以为调用 c.MultipartForm() 就能“自动并行”处理多个文件，其实它只是解析一次 multipart 请求体，返回一个包含所有文件的 map，本身不涉及并发。真正的并行上传必须由客户端发起多个请求（如 Promise.all），或服务端对已解析的文件列表手动 goroutine 分发 —— 但后者有风险。
-
c.MultipartForm()是同步阻塞调用，会一次性读取整个请求体到内存（受router.MaxMultipartMemory限制） - 如果上传 10 个 50MB 文件，且未调大内存限制，默认 32MiB 会直接报
http: request body too large - goroutine 并行保存文件时，若共用同一
os.Create目标路径，可能触发文件覆盖或权限冲突
c.FormFile() 和 c.MultipartForm() 的适用边界
别混用：单文件用 c.FormFile("file")，多文件必须用 c.MultipartForm() 解析字段名匹配的数组（如 upload[] 或 files），否则拿不到全部文件。
- 前端
<input type="file" name="upload[]" multiple>→ 后端用form.File["upload[]"] - 前端
<input type="file" name="files" multiple>→ 后端用form.File["files"]（注意不是files[]） -
c.FormFile("files")永远只返回第一个文件，其余丢弃 —— 这是常见漏传 bug 根源
真正可控的“并行”：用 goroutine + channel 控制并发数
盲目起 100 个 goroutine 保存文件，容易打爆磁盘 I/O 或触发系统 open files 限制。推荐用带缓冲的 channel 做并发控制，比如最多同时写 3 个文件。
sem := make(chan struct{}, 3) // 最大并发数 3
var wg sync.WaitGroup
for _, file := range files {
wg.Add(1)
go func(f *multipart.FileHeader) {
defer wg.Done()
sem <- struct{}{} // 获取信号量
defer func() { <-sem }() // 释放信号量
dst := path.Join("./uploads", f.Filename)
c.SaveUploadedFile(f, dst)
}(file)
}
wg.Wait()- 不加 channel 控制时，100 个文件可能瞬间创建 100 个文件句柄，Linux 默认 ulimit -n 通常为 1024
-
c.SaveUploadedFile()内部调用file.Open()，该操作可能因文件过大或磁盘满失败，需在外层加 error 捕获 - 避免在 goroutine 中直接使用
c（Context 非并发安全），只传*multipart.FileHeader和必要参数
容易被忽略的路径与命名安全点
多文件上传最常栽在文件名上：攻击者上传 ../../../etc/passwd 或空格、Unicode 控制字符，导致写入任意路径或后续处理 panic。
- 永远不用
file.Filename做最终路径，用path.Base(file.Filename)截掉路径部分 - 校验扩展名必须基于文件头（magic bytes），而非后缀 ——
.jpg.exe可能是 PE 文件 - 生成唯一文件名时，别只用
time.Now().UnixNano()，应结合随机字符串，防止时钟回拨冲突
并发本身不难，难的是在并行中守住每一步的边界：内存、句柄、路径、类型。漏掉任意一环，上线后遇到真实用户批量上传就容易雪崩。
