必须先调用 r.ParseMultipartForm 并传入最大内存阈值（单位字节），否则 r.MultipartForm 为 nil，r.FormFile 会返回 http.ErrNotMultipart 或静默失败；默认 32MB 内存缓存，超限写临时文件，不设限易致内存耗尽或 panic。
Go 的 http.HandleFunc 里怎么安全接收 multipart 文件
直接用 r.ParseMultipartForm 而不设限，上传大文件时会吃光内存或触发 panic。Go 默认只缓存 32MB 到内存，超出就写临时文件，但没显式调用前，r.MultipartForm 是 nil，r.FormFile 会返回 http.ErrNotMultipart 或静默失败。
必须先调用 r.ParseMultipartForm 并传入最大内存阈值（单位字节），否则后续读取不可靠：
err := r.ParseMultipartForm(32 << 20) // 32MB 内存上限
if err != nil {
http.Error(w, "invalid multipart form", http.StatusBadRequest)
return
}
-
ParseMultipartForm不是“可选步骤”，而是强制前置操作；漏掉就会让r.FormFile返回错误或空值 - 阈值设太小（如 1MB）会导致多数文件立刻落盘，增加 I/O；设太大（如 512MB）可能被恶意上传拖垮服务
- 该调用会自动解析全部表单字段（包括非文件字段），所以之后也能用
r.PostFormValue
r.FormFile 和 form.File 哪个更可控
r.FormFile("file") 是快捷封装，内部调用 r.MultipartForm.File["file"] 取第一个文件，但隐藏了多文件、错误分类等细节。真实场景中常需处理同名多个文件、校验文件头、跳过空项——这时必须手动访问 r.MultipartForm.File。
例如前端用 <input type="file" name="files" multiple> 上传多个文件：
立即学习“go语言免费学习笔记（深入）”；
files, ok := r.MultipartForm.File["files"]
if !ok {
http.Error(w, "no files uploaded", http.StatusBadRequest)
return
}
for _, fhdr := range files {
file, err := fhdr.Open()
if err != nil {
continue // 跳过打不开的项
}
defer file.Close() // 注意：每个 file 都要单独 defer
// ……处理逻辑
}
-
r.FormFile只返回首个匹配项，且遇到解析错误直接返回 error；r.MultipartForm.File返回切片，便于遍历和容错 -
fhdr.Open()返回的io.ReadCloser必须显式关闭，否则文件句柄泄漏；不能只 defer 一次，要在循环内逐个 defer -
fhdr.Size是上传时声明的大小，不一定可信；真正校验需读取内容或用io.LimitReader控制读取上限
如何防止文件覆盖、路径遍历和空字节注入
用户传来的 fhdr.Filename 是完全不可信的字符串。直接拼接 os.Create(filepath.Join(uploadDir, fhdr.Filename)) 会导致 ../../../etc/passwd 这类路径穿越，或 shell.php%00.jpg 绕过扩展名检查。
安全做法是彻底丢弃原始文件名，用服务端生成的唯一 ID + 白名单扩展名：
ext := filepath.Ext(fhdr.Filename)
if ext != ".jpg" && ext != ".png" && ext != ".pdf" {
http.Error(w, "unsupported file type", http.StatusUnsupportedMediaType)
continue
}
dstPath := filepath.Join(uploadDir, fmt.Sprintf("%s%s", uuid.New().String(), ext))
dst, err := os.Create(dstPath)
- 用
filepath.Ext提取扩展名，而不是用strings.HasSuffix或正则——后者易被archive.zip?x=1.jpg欺骗 - 不要用
filepath.Clean“修复”路径，它无法阻止%00或 Unicode 归一化绕过；最稳妥是忽略原始名 - 如果业务必须保留原名，至少要用
strings.TrimRight(fhdr.Filename, "\x00")清空结尾空字节，并用path.Base截取最后一段
上传进度和超时控制为什么不能只靠 HTTP 超时
HTTP server 的 ReadTimeout 只限制请求头读取时间，对请求体（即文件流）无效。用户上传一个 2GB 文件卡在半路，连接可能挂住十几分钟，而服务端毫无感知。
真正起作用的是 http.Request.Body 的上下文超时，需在 handler 内部显式设置：
ctx, cancel := context.WithTimeout(r.Context(), 30*time.Second)
defer cancel()
r = r.WithContext(ctx)
file, err := fhdr.Open()
if err != nil {
return
}
// 后续 io.Copy 必须用带 ctx 的版本，比如 io.CopyN(dst, file, limit)
// 或用 goroutine + select 监控 ctx.Done()
- 标准
io.Copy不响应 context，必须用io.CopyN配合预估大小，或改用io.Copy包装成可取消版本 - multipart 解析阶段（
ParseMultipartForm）本身不支持中断，所以超时应设在解析后、文件读取前 - 浏览器端上传中断时，TCP 连接可能不立即断开，服务端需依赖底层 net.Conn 的 KeepAlive 和 FIN 包检测，不能全指望应用层 timeout
文件上传不是把数据倒进去就完事，每个环节都有隐性假设：内存配额、路径信任、上下文生命周期。漏掉任意一环，上线后出问题往往不是报错，而是悄无声息地泄露、阻塞或越权。
