必须先调用 r.parsemultipartform 才能使用 r.formfile，因 go 的 multipart 表单采用懒解析机制，未显式调用则 form、multipartform 和 formfile 均不可用，这是为防止超大文件滥用内存的设计。
Go 里 ParseMultipartForm 必须先调用才能读 FormFile
很多人在用 r.FormFile("file") 时 panic 报 http: no such file，或返回 nil，根本原因不是前端没传，而是漏掉了关键一步：必须先调用 r.ParseMultipartForm。
Go 的 http.Request 对 multipart 表单做了懒解析——不显式触发，Form、MultipartForm、FormFile 全部不可用。这不是 bug，是设计上为防内存滥用（比如超大文件直接进内存）。
r.ParseMultipartForm(32 中的参数是最大内存缓存阈值（单位字节），超过此大小的文件会自动流式写入临时磁盘文件- 传
0不代表“不限制”，而是触发默认值32 （32MB），但建议显式写清楚 - 如果只调用
r.ParseForm()，它只会解析application/x-www-form-urlencoded，对multipart/form-data完全无效
上传大文件时 MaxMemory 设太小会导致 io.ErrUnexpectedEOF
当设置的 MaxMemory 小于实际文件大小，Go 会把超出部分写入磁盘临时文件；但如果磁盘写失败（权限不足、空间满、tmpdir 不可写），后续读取时就可能遇到 io.ErrUnexpectedEOF 或静默截断。
这个错误常被误判为网络中断或前端问题，其实后端日志里往往有 open /tmp/...: permission denied 这类隐藏线索。
- 检查
os.TempDir()返回路径是否可写：go run -e 'fmt.Println(os.TempDir())' - 生产环境建议显式指定临时目录：
os.Setenv("TMPDIR", "/var/tmp/myapp") - 若想完全禁用内存缓冲（强制全部落盘），设
MaxMemory = 0，但注意这会让小文件也走磁盘 I/O，影响性能
FormFile 和 MultipartForm.File 的区别与选择
两者都能拿到上传的文件句柄，但行为差异直接影响健壮性：
-
r.FormFile("name")是快捷封装，内部会自动调用ParseMultipartForm（如果还没解析过），但仅限单个 key —— 如果一个 key 对应多个文件（如<input type="file" multiple>），它只返回第一个 -
r.MultipartForm.File["name"]是原始 map，能拿到所有同名文件切片，但前提是已手动调用过ParseMultipartForm - 如果前端用了
multiple，又只用FormFile，就会漏掉除第一个外的所有文件，且无任何报错提示
文件名乱码（中文名变 .jpg）不是 Go 的锅
Go 标准库本身不处理 RFC 5987（带编码的 filename*），只读取原始 filename 字段。浏览器按不同规则填充这两个字段：Chrome/Firefox 会同时发 filename（ISO-8859-1）和 filename*（UTF-8 + percent-encoding），而 Go 默认忽略后者。
所以乱码本质是没做兼容解析，不是编码设置或 Content-Type 问题。
- 手动从
header提取filename*并解码：mime.DecodeWord可处理filename*="utf-8''%E4%BD%A0%E5%A5%BD.jpg"这类 - 更稳妥的做法是：前端上传前用 JS 对文件名做 URL 编码，后端统一 decode；或干脆服务端忽略原始名，用 UUID 重命名
- 别试图改
runtime.GOMAXPROCS或加SetHeader("Content-Transfer-Encoding", "utf-8")—— 这些对 multipart 文件名解析完全无效
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
