parsemultipartform 的内存阈值应设为32mb（32
ParseMultipartForm 的内存阈值怎么设才不崩
设太高会 OOM，太低又频繁写磁盘、拖慢上传速度。关键不是拍脑袋定个数，而是结合业务场景和部署资源来卡死上限。
ParseMultipartForm(32 （32MB）适合单文件 ≤20MB、并发中等的后台管理类接口- 若支持单文件 500MB+，必须设为
64 或更低（比如 <code>8 ），逼它早写临时文件，再用 <code>r.FormFile拿磁盘句柄——别指望大文件进内存 - 永远配合
http.MaxBytesReader做总请求体限制，例如r.Body = http.MaxBytesReader(w, r.Body, 1（1GB），防恶意超长 body 耗尽连接 - 设为
0是危险操作：它会让所有内容都走临时文件，但r.ParseMultipartForm(0)不等于“流式”，只是放弃内存缓存，仍会一次性读完整个 body
为什么 FormFile 拿不到大文件，却没报错
因为 r.ParseMultipartForm 成功了，但大文件被写进了临时目录，而 r.FormFile 返回的是一个指向该临时文件的 multipart.File 句柄——它看起来像普通文件，实则是 os.File，读写都走磁盘。很多人误以为没拿到，其实是没意识到要手动清理或 rename。
-
r.FormFile("file")在大文件场景下返回的file是可 seek 的，handler.Size准确，handler.Filename来自 header，但不校验路径安全 - 不调用
defer file.Close()会导致临时文件句柄泄漏，后续r.MultipartForm.RemoveAll()失效 - 忘记
defer r.MultipartForm.RemoveAll()会让 /tmp 下堆满未清理的 multipart-xxx 临时文件，撑爆磁盘
绕过 ParseMultipartForm 做真流式处理的硬条件
只有当你明确拒绝任何内存缓存、要求边收边转存（比如直传 S3 分段上传、实时音视频转码），才值得上手写 multipart.NewReader。否则就是给自己加复杂度。
- 绝对不能在之前碰过
r.Body：中间件打日志、解 gzip、甚至io.ReadAll(r.Body)都会让后续multipart.NewReader(r.Body, boundary)读到 EOF - 必须用
part.Header.Get("Content-Disposition")手动解析 filename，再做正则白名单（如^[a-zA-Z0-9._-]{1,256}$），否则路径穿越一击必杀 - 每个
part必须显式part.Close()；非文件字段（如title）要用io.Copy(io.Discard, part)清空，不然NextPart()卡住 - 大文件写磁盘时，务必用
os.CreateTemp("", "upload-*")生成随机名，写完os.Rename()，避免竞态和覆盖
文件保存前最常漏掉的三件事
很多上传逻辑跑通了，上线后出问题，往往栽在这三个看似简单、实则必须显式处理的点上。
- 没校验
handler.Header.Get("Content-Type")，仅靠扩展名判断类型——攻击者改个.jpg后缀，里面塞 WebShell，照样过检 - 没限制单次上传文件总数：
len(r.MultipartForm.File["files"]) > 10就该拒掉，防 DoS 式多小文件轰炸 - 保存路径拼接用了
"/upload/" + handler.Filename——没做filepath.Clean()和根目录隔离，../../../etc/passwd一秒越权
file.Close()、r.MultipartForm.RemoveAll()、io.Discard 这些调用不是可选项，是内存和磁盘安全的最后防线。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
