Go 的 ParseMultipartForm 必须先调用才能读取文件，因 http.Request 默认不自动解析 multipart 数据；若未调用，r.MultipartForm 为 nil，r.FormFile 将返回错误或空文件句柄，导致静默失败。
Go 的 ParseMultipartForm 必须先调用才能读取文件
很多开发者在处理表单上传时直接调用 r.FormFile 或遍历 r.MultipartReader()，却没注意 ParseMultipartForm 是前置必要步骤。Go 的 http.Request 默认不会自动解析 multipart 数据——它被懒加载，不调用就为空。
如果不显式调用，r.MultipartForm 为 nil，r.FormFile 会返回 http.ErrNotMultipart 或空文件句柄，但错误信息容易被忽略，导致后续 file.Size 为 0、file.Header 为空等静默失败。
- 必须在读取任何表单字段或文件前调用
r.ParseMultipartForm(maxMemory) -
maxMemory是内存缓冲上限（单位字节），超过此值的文件部分会暂存到磁盘临时文件；建议设为合理值（如32 即 32MB） - 若只上传小文件且想完全内存处理，可设大些；但不要设为 0 或负数，否则会 panic
检查 Content-Type 和 Filename 不能只信前端传来的值
前端通过 input type="file" 提交的 Content-Type（即 file.Header.Get("Content-Type")）和文件名（file.Filename）均可被任意篡改。仅靠它们做校验极易绕过，比如把恶意脚本命名为 avatar.jpg 并声明 image/jpeg。
- 用
file.Open()获取io.Reader后，读取前几个字节做 magic number 检查（如jpeg开头是FF D8 FF） - 使用标准库
net/http.DetectContentType只能用于纯文本/HTML 等简单类型，对二进制文件不可靠，不推荐依赖 - 更稳妥的做法是：用
golang.org/x/image/draw+image.DecodeConfig解析图片头，或用github.com/h2non/filetype库做真实类型探测 -
file.Filename必须过滤路径遍历（如../../etc/passwd），用path.Base(file.Filename)提取基础名
验证文件大小要在 file.Size 读取后立即判断，别等拷贝时才检查
file.Size 是 multipart.FileHeader 字段，在 r.FormFile 返回时已确定，代表客户端声称的文件大小。但它可能被伪造——不过 Go 在解析时已从 multipart boundary 中提取该值，所以比前端 JS file.size 稍可信，但仍非绝对可靠。
立即学习“go语言免费学习笔记（深入）”；
- 应在
r.FormFile成功后立刻检查：if file.Size > 10 - 不要等到
io.Copy到磁盘时再判断，否则攻击者可构造超大文件触发 OOM 或填满磁盘 - 注意：如果调用
ParseMultipartForm时maxMemory小于文件大小，Go 会将超出部分写入临时磁盘文件，此时file.Size仍准确，但实际 I/O 已发生
完整验证流程示例：内存内安全检查 + 类型探测
以下是一个最小可行的表单文件验证逻辑，聚焦「先验、轻量、防绕过」：不做完整解码，只读头部做判断。
func uploadHandler(w http.ResponseWriter, r *http.Request) {
if r.Method != "POST" {
http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
return
}
// 1. 必须先解析 multipart，否则 FormFile 失效
if err := r.ParseMultipartForm(32 << 20); err != nil {
http.Error(w, "invalid form", http.StatusBadRequest)
return
}
file, header, err := r.FormFile("avatar")
if err != nil {
http.Error(w, "no file uploaded", http.StatusBadRequest)
return
}
defer file.Close()
// 2. 检查声明大小
if header.Size > 5<<20 {
http.Error(w, "file too large", http.StatusBadRequest)
return
}
// 3. 清洗文件名，防止路径穿越
safeName := path.Base(header.Filename)
if safeName == "" || safeName == "." || safeName == ".." {
http.Error(w, "invalid filename", http.StatusBadRequest)
return
}
// 4. 读取前 512 字节做类型探测（真实内容）
buf := make([]byte, 512)
n, _ := io.ReadFull(file, buf)
if n < 512 {
buf = buf[:n]
}
kind, _ := filetype.Match(buf)
if kind == filetype.Unknown || (kind.Extension != "jpg" && kind.Extension != "png" && kind.Extension != "gif") {
http.Error(w, "unsupported file type", http.StatusBadRequest)
return
}
// 5. 重置 reader 位置，准备后续保存（需支持 Seek）
if seeker, ok := file.(io.Seeker); ok {
seeker.Seek(0, 0)
}
// ✅ 此时才可安全保存或进一步处理
fmt.Fprintf(w, "OK: %s (%s)", safeName, kind.Extension)
}
真实项目中还要加 MIME 白名单、扩展名二次校验、临时目录权限控制，但核心逻辑逃不开这四步：解析 → 大小截断 → 名称清洗 → 内容探针。最容易被跳过的，是第 4 步——没有它，所有基于 Content-Type 或后缀的校验都形同虚设。
