必须在r.parsemultipartform或r.formfile前用http.maxbytesreader包装r.body，否则大文件会提前耗尽内存；fileheader.size可被客户端伪造，无法替代实时字节流截断。
必须在 r.ParseMultipartForm 或 r.FormFile 调用前，用 http.MaxBytesReader 包装 r.Body，否则大文件可能已开始读取并耗尽内存——这不是“建议”，而是 Go HTTP 处理 multipart 的默认行为。
为什么不能只靠 FileHeader.Size 校验
FileHeader.Size 是从 multipart boundary 解析出来的字段，可被客户端任意伪造。攻击者构造一个声称只有 1KB 但实际是 2GB 的文件，r.FormFile 仍会尝试加载（或落盘），服务端资源已在解析阶段被占用。
- 它不参与请求体字节流的实时截断，仅是解析后的元数据
- 若未前置设限，
r.ParseMultipartForm可能已把整个 body 缓冲进内存或临时磁盘 - 即使你后续
if header.Size > 5<code>，也晚了
http.MaxBytesReader 必须放在最开头
它要包装原始 r.Body，在任何表单解析逻辑之前生效。一旦你调用了 r.FormFile、r.ParseForm 或甚至 r.PostForm，Go 就可能已触发隐式解析，失去拦截机会。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 正确写法：
r.Body = http.MaxBytesReader(w, r.Body, 10<code> - 错误写法：先
r.ParseMultipartForm(32<code>再包装r.Body—— 此时请求体可能已读完 - 注意：该限制包含所有表单字段 + 所有文件字节，不是“仅文件大小”。若含多个文本字段，需预留余量
ParseMultipartForm 不是上传大小限制，而是内存策略开关
它的参数 maxMemory 控制的是“多少字节以内放内存，超了写临时磁盘”，并不阻止客户端发送超大请求。它和 MaxBytesReader 职责完全不同。
- 设
r.ParseMultipartForm(32<code>：≤32MB 的文件部分进内存，其余落盘；但客户端仍可发 10GB 请求，只要MaxBytesReader没拦住，服务端就会持续接收并写磁盘 - 设为
0会让全部内容落盘，但磁盘空间同样可被耗尽，且无总长度防护 - 跳过该调用、直接用
r.MultipartReader()是纯流式处理的唯一方式，但需手动解析 boundary 和字段，复杂度高
真正容易被忽略的是：Go 的 multipart 解析器在首次访问表单数据时会自动调用 ParseMultipartForm(32<code>（默认值）。这意味着你不显式调用它，也不等于“没解析”——只是用了默认阈值。所以，MaxBytesReader 是唯一能确保在字节流层面就中断恶意请求的机制，且必须出现在 handler 最顶部，不能有任何前置读取操作。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
