multipart.FormValue 无法获取文件字段，因为它只解析非文件类表单值（如text、hidden），跳过type="file"字段；需先调用r.ParseMultipartForm或r.ParseForm，再用r.FormValue取文本、r.FormFile取文件。
multipart.FormValue 为什么拿不到文件字段
因为 multipart.FormValue 只读取非文件类字段（即 text、hidden 等普通表单值），遇到 type="file" 字段会直接跳过——它不解析 multipart/form-data 的文件块，只处理纯文本部分。
常见错误现象：前端传了 name="avatar" 文件和 name="title" 文本，后端用 r.FormValue("avatar") 得到空字符串，但 r.FormValue("title") 正常。
- 正确做法是先调用
r.ParseMultipartForm（或r.ParseForm，它内部会自动处理 multipart） - 再用
r.FormValue("title")拿文本，用r.MultipartReader()或r.FormFile("avatar")拿文件 - 注意：如果没提前 Parse，
r.FormValue在 multipart 请求里可能返回旧缓存值或空，行为不稳定
ParseMultipartForm 的 maxMemory 参数设多少才安全
这个参数控制 Go 在内存中缓存 multipart 数据的上限（单位字节），超过部分会写入临时磁盘文件。设太小会导致频繁落盘、IO 增加；设太大可能被恶意上传耗尽内存。
典型使用场景：用户头像上传（几 MB）、配置文件导入（几十 KB）、日志批量上报（可能上百 MB）。
立即学习“go语言免费学习笔记（深入）”；
- 默认值是
32 （32MB），对大多数 Web 表单够用 - 如果明确只收小文件（如 JSON 配置 + 小图标），可设为
10 （10MB） - 若允许大文件上传，必须设更大值，但建议同步限制
Content-Length头（用中间件拦截超长请求），否则攻击者可发超大 body 卡住ParseMultipartForm - 设为
0是非法的，会 panic；设为负数会被当作0
FormFile 和 MultipartReader 的分工怎么选
r.FormFile("field") 是快捷封装，适合单个已知字段名的文件；r.MultipartReader() 返回底层 multipart.Reader，适合需要逐块解析、跳过某些 part、或处理同名多文件的场景。
容易踩的坑：用 FormFile 读完一个文件后，再想用 MultipartReader 继续读其他 part，会失败——因为 FormFile 内部已消费了整个 multipart body 流，后续读取返回 EOF。
- 只读一个文件且字段名确定 → 用
FormFile，简单清晰 - 要读多个不同 name 的文件 → 分别调用多次
FormFile（Go 1.19+ 支持） - 要过滤/跳过某些 part、或字段名动态生成（如
files[0]、files[1]）→ 必须用MultipartReader+ 手动NextPart() - 所有操作都必须在
ParseMultipartForm之后进行，否则FormFile返回 error，MultipartReader返回 nil
中文文件名乱码或丢失的根源在哪
根本原因是 RFC 7578 没强制规定文件名编码，浏览器实现不一：Chrome / Edge 用 UTF-8 编码并加 filename*=UTF-8''xxx，Firefox 有时用 raw ISO-8859-1，Safari 更混乱。Go 的 multipart.FileHeader.Filename 直接取 filename= 后的原始字节，不做解码。
表现就是：中文名变成一堆 或截断成空字符串。
- 不要直接信任
header.Filename，先检查header.Header.Get("Content-Disposition")是否含filename*= - 用第三方库如
github.com/gogf/gf/v2/util/gutil的ParseFilename，或自己解析filename*并用url.PathUnescape+charset.Decode - 更稳妥的做法：前端上传时，由 JS 对文件名做
encodeURIComponent，后端用url.PathEscape解，绕过 header 编码歧义 - 注意：Nginx 等代理可能重写
Content-Disposition，导致原始 header 丢失
multipart 解析不是“调个函数就完事”的事——字段边界、内存水位、编码歧义、流消费顺序，每个点都卡在实际请求的毛细血管里。漏掉任意一环，都会在某个用户上传时突然崩掉。
