ParseMultipartForm 的 MaxMemory 参数控制内存中缓存的 multipart 数据量上限，而非总上传大小；超出部分自动落盘，但需配合 http.MaxBytesReader 防御大请求体。
ParseMultipartForm 的 MaxMemory 参数到底控制什么
它只控制「小文件进内存」的阈值，不是总内存上限。小于该值的 multipart.FileHeader 对应内容会缓存在内存 buffer 中；超过的则写入系统临时目录（如 /tmp）的磁盘文件。这个参数不阻止大请求体整体加载——r.ParseMultipartForm(32 仍会把整个 multipart body 预读一遍，只是分发策略不同。
常见误用：r.ParseMultipartForm(0) 并非“不限内存”，而是强制所有文件落盘，且失去内存加速路径，性能更差；设为负数会 panic；设得过大（如 1 ）等于邀请 OOM。
- 推荐值：32MB（
33554432），兼顾中小文件响应速度与大文件兜底安全 - 该值必须在调用
r.FormFile或访问r.MultipartForm前设置，否则r.MultipartForm为nil - 它不影响
Content-Length校验，恶意客户端仍可发超长 header 或伪造 size
为什么 FormFile 打开的 file 可能是内存或磁盘，但 Close 必须调用
multipart.File 是 io.ReadCloser，底层可能是 *bytes.Reader（内存）或 *os.File（磁盘临时文件）。Go 不暴露具体类型，但 Close() 行为不同：内存 buffer 的 Close 是空操作；磁盘文件的 Close 会触发 os.Remove 清理临时文件。
漏掉 file.Close() 的后果不是立即报错，而是 /tmp 下堆积大量 multipart-xxx 临时文件，直到磁盘满或手动清理。
立即学习“go语言免费学习笔记（深入）”；
- 即使你用
io.CopyN(dst, file, limit)提前退出读取，也必须Close() - 在
defer file.Close()前要检查file != nil，因为字段名不匹配时r.FormFile返回(nil, nil) - 不要依赖
file.Header.Size判断是否落盘——它只是 header 声明值，和实际存储位置无关
多文件场景下如何避免 total size 超限却未拦截
r.MultipartForm.File["files"] 是切片，每个 *multipart.FileHeader 的 Size 字段是独立声明的。攻击者可构造多个小文件（如 1000 个 9MB 文件），绕过单文件 10MB 限制，总上传达 9GB。
必须在遍历前初始化累计计数器，并在每次 file.Open() 前校验累加值是否超总上限，而不是仅校验单个 file.Header.Size。
- 示例：设总限 50MB，则循环中做
totalSize += header.Size，超限时直接http.Error(w, "total size exceeded", http.StatusBadRequest) - 注意：
header.Size仍不可信，仅作前置快速拦截；真实大小以io.Copy返回值为准 - 若需精确控流，对每个
file用io.LimitReader(file, maxSingleFileSize)包一层，防止单个文件超限
真正流式处理：绕过 ParseMultipartForm 的必要条件
当上传文件普遍 >100MB 或需严格控制内存峰值时，ParseMultipartForm 的预读行为已成瓶颈。此时必须放弃它，改用 multipart.NewReader 手动解析——但这要求你完全接管 boundary 提取、part 消费、错误恢复和临时资源清理。
关键动作缺一不可：用 mime.ParseMediaType 从 Content-Type 安全提取 boundary；对每个 part 调用 io.Copy 或 io.CopyBuffer 完整消费（哪怕丢弃）；对目标 part 显式限速限大小；自己创建并管理临时文件，而非依赖 Go 自动分配。
- 错误示范：只读
part前几 KB 就break，会导致后续NextPart()错位，整个请求体解析失败 - boundary 硬编码或字符串分割（如
strings.Split(ct, "boundary=")）在真实环境中极易因 header 格式变化崩溃 - 这种模式下，
http.MaxBytesReader仍是必需的第一道防线，但它只管总字节数，不管内存峰值
