必须先调用 r.ParseMultipartForm 才能解析 multipart 表单，因 Go 采用惰性解析机制，未显式调用则 r.MultipartForm 为 nil，r.FormFile 等操作会 panic 或返回空；参数如 32<<20 指定内存缓冲上限，超限部分自动落盘。
为什么 r.ParseMultipartForm 必须在读取文件前调用
Go 的 http.Request 对 multipart 表单的解析是惰性的——不显式调用 r.ParseMultipartForm，r.MultipartForm 就是 nil，后续所有 r.FormFile 或 r.MultipartForm.File 操作都会 panic 或返回空。这不是 bug，是设计：避免小表单也触发完整解析开销。
常见错误现象：panic: multipart: NextPart: EOF 或 no such file，往往是因为漏了这步，或调用位置不对（比如在 if r.Method == "POST" 外调用）。
实操建议：
- 必须在
if r.Method == "POST"分支内、且在任何FormFile调用前执行 - 传入的内存上限参数（如
32 ）代表最多将多少字节的 form data 缓存在内存中；超出部分会自动写入临时磁盘文件，不影响功能但影响性能 - 若只上传文件、无其他表单字段，可设为较小值（如
1 ），减少内存占用
r.FormFile 和 r.MultipartForm.File 选哪个
r.FormFile("file") 是快捷封装，内部会先检查是否已解析，未解析则自动调用 ParseMultipartForm(32 ；而 <code>r.MultipartForm.File["file"] 要求你确保已手动解析且 MultipartForm 非 nil。
推荐直接用 r.FormFile，除非你需要同时读多个同名文件（此时 r.MultipartForm.File 返回 []*multipart.FileHeader，更可控）。
注意点：
-
r.FormFile只返回第一个同名文件，即使 HTML 中有多个<input type="file" name="file" multiple>，它也只取第一个 - 如果用了
multiple，必须用r.MultipartForm.File["file"]并遍历切片 -
r.FormFile返回的*multipart.FileHeader包含Filename、Size、Header，但不包含文件内容；要读内容得再调file.Open()
保存上传文件时，file.Open() 和 io.Copy 怎么配
file.Open() 返回一个 io.ReadCloser，不是原始字节流；直接读可能遗漏 close，导致 fd 泄露或临时文件无法清理。
标准做法是组合 file.Open() + os.Create() + io.Copy()，并确保所有资源被关闭：
src, err := file.Open()
if err != nil {
http.Error(w, "cannot open file", http.StatusInternalServerError)
return
}
defer src.Close()
dst, err := os.Create("/tmp/" + file.Filename)
if err != nil {
http.Error(w, "cannot create file", http.StatusInternalServerError)
return
}
defer dst.Close()
if _, err = io.Copy(dst, src); err != nil {
http.Error(w, "copy failed", http.StatusInternalServerError)
return
}
关键细节：
- 必须
defer src.Close()，否则 Go 不会自动清理临时磁盘文件（尤其大文件） - 不要用
ioutil.ReadAll(src)加载整个文件到内存，容易 OOM；io.Copy是流式处理，内存占用恒定 - 注意
file.Filename是客户端传来的原始文件名，不可信；生产环境应重命名，避免路径遍历（如../../etc/passwd）
为什么上传大文件时连接会超时或中断
默认 HTTP server 没有为 multipart 请求单独设置超时，但有两个隐性瓶颈：一是 http.Server.ReadTimeout（从连接建立到读完请求头+body 的总时间），二是 ParseMultipartForm 的内存/磁盘策略引发阻塞。
典型表现：上传 100MB 文件时，前端卡在 pending，后端日志无记录，几秒后报 connection reset 或 i/o timeout。
解决方向：
- 调大
http.Server.ReadTimeout和ReadHeaderTimeout（例如设为 60 秒） - 给
ParseMultipartForm传足够大的内存阈值（如100 ），减少磁盘 I/O 频次 - 更稳妥的做法是配合前端分片上传，服务端用
multipart.Reader手动解析流，绕过ParseMultipartForm的整包限制
真正难处理的从来不是“怎么存”，而是“怎么不让大文件拖垮整个服务”——内存缓冲区大小、超时配置、临时目录磁盘空间、客户端断连重试逻辑，这些才是线上出问题时最先暴露的环节。
