multipart.FileHeader 是 Go 中描述上传文件元数据的结构体，能获取文件名（fh.Filename）和大小（fh.Size），但文件名可能被污染或截断，Size 在完整解析时可信但流式中断时可能偏小。
Go 里 multipart.FileHeader 是什么，它真能拿到文件名和大小吗
multipart.FileHeader 是 Go 标准库 mime/multipart 包中用于描述上传文件元数据的结构体。它不是“文件内容”，只是 HTTP multipart 表单中每个 file 字段对应的头部信息——比如你用 input type="file" 上传一个 report.pdf，它的名字、大小、MIME 类型就存在这个结构里。
但它**不保证字段齐全**：浏览器提交时可能不带 Content-Type（导致 Header.Get("Content-Type") 返回空），也可能把原始文件名丢在 Filename 字段里但被截断或污染（比如含路径、空格、Unicode）。别指望它 100% 可靠。
常见错误现象：
• fh.Size 显示 0，但文件实际有内容
• fh.Filename 是 "C: akepathvatar.jpg"（Chrome）或空字符串（某些 iOS Safari）
• fh.Header.Get("Content-Type") 返回 "" 或 "application/octet-stream"
-
fh.Size是服务端解析出的字节数，可信；但若前端用流式上传且未写完就断开，ParseMultipartForm可能只读到部分数据，此时fh.Size小于真实大小 -
fh.Filename来自 HTTP 请求头中的filename=...参数，无法验证是否真实存在该文件，也不能直接用于磁盘保存（路径遍历风险！） -
fh.Header是原始 MIME 头，可用fh.Header.Get("Content-Type")获取类型，但浏览器常不填或乱填，建议后续用net/http.DetectContentType或file命令检测实际内容
从 *http.Request 提取 multipart.FileHeader 的标准流程
必须先调用 r.ParseMultipartForm，否则 r.MultipartForm 为 nil，r.FormFile 或 r.MultipartForm.File 都会 panic 或返回错误。
立即学习“go语言免费学习笔记（深入）”；
注意：这个方法会把整个 multipart body 读入内存或临时文件（取决于 maxMemory 参数），超限后自动落盘。如果没设上限又上传大文件，可能 OOM。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 调用
r.ParseMultipartForm(32 （即 32MB）是安全起点，比默认的 32KB 更实用 - 用
fh, err := r.FormFile("avatar")最简，适合单文件字段；返回*multipart.FileHeader和一个io.ReadCloser（记得defer fh.Close()） - 用
if r.MultipartForm != nil { files := r.MultipartForm.File["avatar"] }可处理多文件同名字段，files是[]*multipart.FileHeader - 别跳过
err检查：常见错误包括http.ErrNotMultipart（非 multipart 请求）、multipart.ErrMessageTooLarge（超maxMemory且没配临时目录）
multipart.FileHeader 的常见误用与绕过方案
很多人以为 fh.Filename 就是“用户选的文件名”，直接拼进 os.OpenFile 路径，结果被 ../../etc/passwd 攻击；或者用 fh.Size 当唯一校验，忽略客户端伪造可能。
真正落地时要主动清洗和补充：
- 文件名必须清理：
filepath.Base(fh.Filename)去掉路径，再用正则替换非法字符（如[ - /\:*?"<>|]），避免系统拒绝或覆盖 - 大小不能全信：
fh.Size是 header 声明值，实际读取时应通过io.CopyN或io.LimitReader控制最大接收量，并检查最终写入字节数是否匹配 - MIME 类型需二次确认：先取
fh.Header.Get("Content-Type")，再读前 512 字节传给http.DetectContentType，两者都不可信时按扩展名 fallback（如.jpg→image/jpeg） - 不要依赖
fh.Header里的其他字段（如Content-Disposition全字段），不同浏览器序列化格式不一致，解析易出错
为什么有时候 fh.Size == 0 却还能读到内容
这是 Go 的一个隐式行为：当 multipart boundary 解析失败、或请求体被提前关闭（如客户端中断上传），ParseMultipartForm 可能仍返回部分 FileHeader，但 Size 字段未正确填充，而底层 io.ReadCloser 仍可读取已接收的数据。
这不是 bug，是流式解析的副作用。生产环境必须同时校验两个维度：
- 先检查
fh.Size > 0，不满足则记录 warn 日志并拒绝（除非业务允许零字节上传） - 读取时用
io.LimitReader(f, maxFileSize)，防止恶意构造超大 body 导致内存耗尽 - 读完后对比
actualRead和fh.Size：若fh.Size > 0 && actualRead != fh.Size，说明传输不完整，应删除临时文件并返回 400
最麻烦的是，这种不一致在本地开发时很难复现，往往只在弱网、移动端或 CDN 中转后出现。上线前务必用 curl -F "file=@/dev/zero" ... 和中断上传模拟测试。
