r.ParseMultipartForm 传入 0 或负数会 panic，因 Go 要求 MaxMemory 必须大于 0；默认不调用时使用 32MB。
为什么 r.ParseMultipartForm 会 panic: multipart: MaxMemory of 0
这是最常遇到的报错，直接导致服务崩溃。根本原因是调用 r.ParseMultipartForm 时传入了 0 或负数作为内存上限参数，而 Go 标准库明确要求该值必须大于 0。
- 默认不调用
ParseMultipartForm时，Go 会用32 （即 32MB）作为隐式上限；但一旦显式调用，就必须传正整数 - 常见错误写法：
err := r.ParseMultipartForm(0)
或r.ParseMultipartForm(-1)
- 正确做法是至少传
1（单位为字节），例如：err := r.ParseMultipartForm(32 << 20) // 32MB
- 若想完全禁用内存缓冲、强制全部写入临时磁盘文件，可设为极小值（如
1），但注意这会增加 I/O 开销
如何安全读取 *multipart.FileHeader 并防止路径遍历
FileHeader.Filename 是客户端可控字段，未经处理直接拼接 os.OpenFile 路径会导致目录穿越（如上传 ../../etc/passwd）。
- 永远不要直接使用
header.Filename构造文件路径 - 推荐做法：忽略原始文件名，生成服务端唯一 ID（如
uuid.New().String()），再根据 MIME 类型补全后缀 - 若需保留原始名称，必须先清洗：
filename := path.Base(filepath.Clean(header.Filename))
，再白名单校验扩展名（如只允许.jpg,.pdf） - 写入前务必检查目标目录是否在允许根路径内，例如：
absPath, _ := filepath.Abs(filepath.Join(uploadDir, safeName))<br>if !strings.HasPrefix(absPath, uploadDir) {<br> http.Error(w, "invalid filename", http.StatusBadRequest)<br> return<br>}
如何限制单个请求的总上传大小和文件数量
ParseMultipartForm 只控制内存缓冲区大小，不约束整个请求体或文件总数。要真正防爆，得配合 http.MaxBytesReader 和手动计数。
- 全局限制请求体大小（含所有字段 + 文件）：
r.Body = http.MaxBytesReader(w, r.Body, 10<<20) // 10MB 总上限
，超限会返回413 Request Entity Too Large - 解析后检查文件数量：
if len(r.MultipartForm.File) > 5 {<br> http.Error(w, "too many files", http.StatusBadRequest)<br> return<br>} - 逐个检查单个文件大小（
header.Size是准确的，无需打开文件）：for _, headers := range r.MultipartForm.File {<br> for _, h := range headers {<br> if h.Size > 5<<20 { // 单文件超 5MB<br> http.Error(w, "file too large", http.StatusBadRequest)<br> return<br> }<br> }<br>}
为什么 r.FormValue 在 multipart 请求中有时拿不到普通字段
如果在调用 r.ParseMultipartForm 前就调用 r.FormValue，可能返回空字符串——因为 multipart 表单的非文件字段也属于 multipart boundary 内容，必须先解析整个表单才能提取。
立即学习“go语言免费学习笔记（深入）”；
- 正确顺序：先
r.ParseMultipartForm，再用r.FormValue或r.PostFormValue - 更稳妥的做法是统一用
r.MultipartForm.Value获取普通字段：if r.MultipartForm == nil {<br> err := r.ParseMultipartForm(32 << 20)<br> if err != nil { /* handle */ }<br>}<br>title := r.MultipartForm.Value["title"][0] - 注意：
r.FormValue在 multipart 请求中仍可用，但依赖内部自动触发解析；显式调用ParseMultipartForm后再访问更可靠
实际部署时最容易被忽略的是：没有在 defer f.Close() 前校验 f 是否为 nil，而 r.FormFile 在文件不存在时返回 nil, nil，直接 defer 会 panic。这个细节在压测或异常请求下才暴露。
