parsemultipartform 报错“http: max memory exceeded”是因为未调用该方法或传入内存上限过小；go 默认不自动解析 multipart 数据，需显式调用并设置合理值（如 32
文件上传时 ParseMultipartForm 报错 http: max memory exceeded
这是最常卡住新手的第一步：没调用 ParseMultipartForm 或传了过小的内存上限，导致后续 r.MultipartReader() 直接 panic。
Go 的 http.Request 默认不自动解析 multipart 数据，必须显式调用，且第一个参数是「最多允许读入内存的字节数」。超过的部分会暂存到磁盘临时文件——但如果你设成 0 或太小（比如 1KB），而用户上传了 5MB 的图片，就会触发这个错误。
- 务必在
r.ParseMultipartForm中传入合理值，例如32 （32MB） - 如果业务明确只收小图，也别设低于 4MB，否则连普通手机拍照都可能失败
- 该调用必须在访问
r.FormFile、r.MultipartReader()或r.PostForm之前执行，顺序错了也会报错
保存上传文件前必须用 filepath.Clean 处理原始文件名
用户提交的 filename 是完全不可信的，可能含 ../、空字节、控制字符或超长路径。直接拼进 os.OpenFile 路径里，轻则写错位置，重则覆盖配置文件甚至执行目录穿越。
filepath.Clean 不是防注入银弹，它只做路径标准化，但配合白名单校验才真正安全。
立即学习“go语言免费学习笔记（深入）”；
- 先用
filepath.Base提取纯文件名，再用filepath.Clean去掉点号路径成分 - 强制替换掉所有非字母数字、下划线、短横和点号的字符（正则
[^a-zA-Z0-9_.-]） - 生成保存路径时，永远以你指定的根目录开头，例如
filepath.Join(uploadDir, safeName)，绝不拼接原始Header.Get("filename")
FormFile 和 MultipartReader 的选择取决于是否需要流式处理
多数后台只需保存文件，用 r.FormFile 最简单；但若要边上传边校验内容（比如检查 PNG 签名、计算 SHA256、或转发给 MinIO），就得用 r.MultipartReader 手动迭代 Part。
两者底层共享同一个 reader，不能混用：一旦调用了 FormFile，再调 MultipartReader 就会返回空或报错。
- 只存文件？直接
file, header, err := r.FormFile("file")，然后io.Copy到目标*os.File - 需流式处理？先
r.ParseMultipartForm，再mr, err := r.MultipartReader()，循环mr.NextPart()拿每个 part - 注意
header.Header.Get("Content-Type")可能为空，别依赖它判断文件类型，应读取前几百字节做 magic number 校验
生产环境必须限制上传总大小和单个请求超时
原生 http.Server 默认不限制请求体大小，攻击者发一个 2GB 的 multipart/form-data 请求就能让服务长时间阻塞、OOM 或填满磁盘。
超时同样关键：上传慢不是 bug，但让它无限挂起会耗尽连接池。
- 用
http.MaxBytesReader包裹r.Body，例如http.MaxBytesReader(w, r.Body, 100（100MB 总限） - 设置
http.Server.ReadTimeout和ReadHeaderTimeout，建议都设为 30 秒以内 - 不要只靠前端 JS 限制文件大小——那层毫无意义，后端才是唯一防线
真正难的不是把文件存下来，而是确保同一份上传请求里，文件名、内容、元数据三者始终一致，且整个过程可中断、可回滚、可审计。比如保存失败时临时文件没清理，或者并发上传同名文件覆盖了旧版——这些细节不会报错，但会让后台慢慢变成黑洞。
