go 文件上传必须先调 parsemultipartform，否则 r.formfile 和 r.multipartform.file 均失效；常见错误是未调用或调用过晚（如在 formvalue 后），导致返回 http.errnotmultipart。
Go 处理 HTTP 文件上传，核心就一条：不调 ParseMultipartForm，r.FormFile 和 r.MultipartForm.File 都会失效——不是 bug，是设计前提。
为什么 r.FormFile 总返回 http.ErrNotMultipart
常见现象：前端明明用了 enctype="multipart/form-data"，后端却拿不到文件，r.FormFile("file") 直接返回 http.ErrNotMultipart 或 nil。
- 根本原因：没调
r.ParseMultipartForm，或调得太晚（比如在r.FormValue之后） -
r.FormFile内部会尝试自动调一次ParseMultipartForm(32 ，但前提是 <code>r.MultipartForm == nil；如果之前手动调过且参数不同，会 panic - 别用
r.ParseForm()替代——它对 multipart 完全无效，还可能让后续ParseMultipartForm报http: multipart handled - 调试时别写
io.ReadAll(r.Body)，这会把底层 reader 耗尽，导致后续所有解析失败
ParseMultipartForm 的 maxMemory 参数怎么设
这个参数决定多少字节以内留在内存、超了写哪——直接影响性能、安全和稳定性。
- 设太小（如
1）：所有稍大点的文件都强制落盘，但若os.TempDir()不可写或磁盘满，上传直接失败 - 设太大（如
500）：并发高时容易 OOM，尤其服务本身内存紧张 - 默认值是
32 （32MB），但不调 <code>ParseMultipartForm就不会生效，实际沿用的是未显式设置时的 32KB - 建议按场景分档：
10（纯小图/文本）、100（含 ZIP/MP4）、500（专业媒体上传），并确保os.TempDir()有写权限且空间充足
用 r.MultipartForm.File 取多个同名文件
当 HTML 是 <input type="file" name="files" multiple>，或页面里有多个 name="file" 字段时，r.FormFile 只能取第一个，必须换方式。
- 先确保已调
r.ParseMultipartForm(maxMemory) - 再访问
r.MultipartForm.File["files"]，它返回[]*multipart.FileHeader，可遍历处理每个文件 - 每个
FileHeader包含Filename、Size、Header，比FormFile返回的单个句柄更可控 - 别反复调
r.FormFile("files")——第二次调用大概率返回空或 error，因为内部 reader 已被重置
保存文件前必须做的三件事
客户端传来的 Filename 是不可信输入，直接拼路径等于开放任意文件写入。
- 丢弃原始路径：用
filepath.Base(header.Filename)提取文件名，再用白名单校验扩展名（如只允许.jpg、.pdf） - 生成服务端唯一名：用
uuid.New().String()或time.Now().UnixNano()，拼上可信扩展名，例如uuid + ".jpg" - 确保目录存在且权限合理：调
os.MkdirAll(uploadDir, 0755)，再用os.Create或os.OpenFile写入 - 永远别用
filepath.Clean()“修复”路径——它防不住%2e%2e、....//等绕过手段
最易被忽略的其实是顺序：ParseMultipartForm 必须在任何读取操作之前，且只能调一次；而文件名校验和大小限制，必须在打开 file.Open() 之前做，否则可能已触发磁盘写入或内存分配。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
