因为 readform 默认只缓存文本字段，文件字段会被跳过——它内部调用 parsemultipartform 时未设置足够 maxmemory，导致文件被丢弃；实操须显式调用 r.parsemultipartform(32
multipart.ReadForm 为什么读不到文件字段
因为 ReadForm 默认只缓存文本字段，文件字段会被跳过——它内部调用的是 ParseMultipartForm，但没把 MaxMemory 设够，或者压根没设，导致文件直接被丢弃。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须显式调用
r.ParseMultipartForm(32 （例如 32MB），且要在 <code>r.FormValue或r.MultipartReader之前 -
MaxMemory是内存阈值，超过的部分会写入临时文件；设为 0 不代表不限制，而是退化为纯磁盘模式，性能差且可能失败 - 如果只想要文件，别依赖
ReadForm，直接用r.MultipartReader()+ 手动遍历NextPart
如何安全读取 multipart.File 而不阻塞或 OOM
Go 的 multipart.File 是个 io.ReadCloser，但底层可能是内存 buffer 也可能是临时文件句柄。不手动控制读取长度，容易在恶意上传时耗尽内存或卡死。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 永远用
io.LimitReader(file, maxFileSize)包一层，比如限制单个文件 ≤10MB - 读完后务必调用
file.Close()，否则临时文件不清理，/tmp会堆积 - 不要用
io.ReadAll直接读整个multipart.File，尤其对视频、压缩包这类大文件 - 如果需要校验文件头（如判断是否为 PNG），用
bytes.Peek或先读固定字节，别全读
multipart.Part.Header 中的 filename 怎么提取才可靠
Part.Header.Get("Content-Disposition") 返回的字符串格式不统一：有的带 filename="中文.jpg"，有的是 filename*=UTF-8''%E4%B8%AD%E6%96%87.jpg，还有的压根没 filename（比如纯文本字段）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别自己正则解析，用标准库函数：
mime.Basename(part.FileName())—— 它已处理filename*编码和引号转义 -
part.FileName()返回空字符串不等于“没有文件”，可能是字段名匹配但没传值，要结合part.FormName()判断用途 - 浏览器上传时，字段名是
file，但服务端收到的part.FormName()可能是""（如果用了FormData.append('file', blob)而没指定第三参数）
multipart.Reader 解析失败：unexpected EOF 或 invalid byte in boundary
常见于前端用 fetch + FormData 提交，但后端没设好请求体解析上下文；或 Nginx / Caddy 做了代理却截断了大 body。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 检查
Content-Type请求头是否完整包含boundary=...，缺失或格式错误会导致multipart.NewReader初始化就 panic - Nginx 需确认配置了
client_max_body_size和client_body_buffer_size，否则大文件上传会在代理层被截断，后端看到的是残缺流 - 用
curl -v抓原始请求，看 boundary 是否出现在 header 里、是否与 body 中的分隔符一致（注意换行符是\r\n，不是\n） - 如果用自定义
multipart.NewReader，确保传入的io.Reader是可重读的，比如包装成io.MultiReader前先bytes.NewReader缓存前几 KB
边界解析器对换行和空格极其敏感，一个错位的 \r 就会让整个 multipart 流失效——这不是 Go 实现的问题，是 MIME 规范本身的要求。
