不能直接对*multipart.FileHeader调用Read()，因其未实现io.Reader接口；必须先调Open()获取io.ReadCloser，再用io.ReadAll加载全部内容到内存，且需校验长度是否等于Size。
不能直接在内存中“读取上传的文件流”——c.FormFile 返回的 *multipart.FileHeader 本身不是流，也不含文件内容；它只是元信息+一个可打开的句柄。所谓“在内存中读取”，本质是调用 Open() 后用 io.ReadAll 把整个流加载进 []byte。这可行，但有明确前提和代价。
为什么不能对 FileHeader 直接调 Read()
常见错误是把 fileHeader 当成 io.Reader 用：fileHeader.Read(buf) 会 panic，因为 *multipart.FileHeader 没实现 io.Reader 接口。它只提供 Open() 方法来获取真正的读取器。
-
fileHeader.Size是文件大小（可用于预分配切片） -
fileHeader.Filename是原始文件名（需清洗+编码，不能直接拼路径） -
fileHeader.Open()才返回multipart.File（即io.ReadCloser）
用 io.ReadAll 加载到内存的正确写法
适用于小文件（比如配置 XML、JSON、小于 10MB 的图片），不适用于日志、视频、报表等大文件——否则直接 OOM。
- 必须先
file, err := c.FormFile("file")，检查err - 再
src, err := file.Open()，检查err，并defer src.Close() - 然后
data, err := io.ReadAll(src)，这才是真正把全部内容读进内存 - 别忘了校验
len(data)是否等于file.Size（防止读半截）
file, err := c.FormFile("config")
if err != nil {
c.JSON(400, gin.H{"error": "no file uploaded"})
return
}
src, err := file.Open()
if err != nil {
c.JSON(500, gin.H{"error": "failed to open file"})
return
}
defer src.Close()
data, err := io.ReadAll(src)
if err != nil || int64(len(data)) != file.Size {
c.JSON(500, gin.H{"error": "incomplete read"})
return
}
// data 就是完整字节切片，可 xml.Unmarshal 或 json.Unmarshal
MaxMultipartMemory 是关键限制，不是可选配置
Gin 默认只允许 32MB 内存缓存 multipart 数据；超过这个值，c.FormFile 会自动把文件暂存到磁盘临时目录（/tmp），此时 Open() 返回的是磁盘文件句柄，而非内存映射。你以为在读内存，其实已在 IO 等待。
- 该限制由
r.MaxMultipartMemory = 8 << 20控制（单位字节），必须在gin.Default()后立即设置 - 设太大（如 512MB）会导致高并发时内存暴涨，被系统 OOM kill
- 设太小（如 1MB）会让稍大的 PNG/ZIP 被刷到磁盘，性能下降且临时文件需清理
- 它只影响上传解析阶段，和后续
io.ReadAll无关——后者读的是Open()返回的流，不管来源是内存还是磁盘
真正需要流式处理时，别碰 io.ReadAll
如果文件可能超 10MB，或你只需要解析前几 KB（比如读 Excel 表头、抽日志时间戳、校验 ZIP 签名），就不要加载整块内存。直接用 io.Copy 或带缓冲的 bufio.Reader 边读边处理。
-
io.Copy(ioutil.Discard, src)可跳过全部内容（用于快速校验是否存在） -
buf := make([]byte, 4096); n, _ := src.Read(buf)可读开头一段做 sniff - XML/JSON 解析应使用
xml.NewDecoder(src)或json.NewDecoder(src)，它们内部流式解码，不依赖全文载入
最常被忽略的一点：无论你选内存加载还是流式处理，file.Open() 后的 Close() 都不能省——漏掉会导致临时文件句柄泄漏，/tmp 下堆满未清理的 multipart-xxx 文件。
