不能直接对*multipart.FileHeader调用Sum()，因为它仅含元信息而不实现io.Reader；必须先调用Open()获取multipart.File流，再用io.Copy边读边哈希，避免OOM和句柄泄漏。
为什么不能直接对 *multipart.FileHeader 调用 Sum()
因为 *multipart.FileHeader 本身不实现 io.Reader，它只是文件元信息（如文件名、大小、头信息），真正可读的流需要通过 c.FormFile() 返回的 *multipart.FileHeader 调用 Open() 获取。直接对 fileHeader 做哈希会 panic 或返回空值。
常见错误现象：panic: interface conversion: interface {} is *multipart.FileHeader, not io.Reader 或哈希结果始终是空字符串的零值。
- 必须先调用
fileHeader.Open()得到multipart.File（实现了io.ReadCloser） - 哈希计算必须在读取流的过程中进行，不能先保存再算——否则多一次磁盘 I/O，且大文件易 OOM
- 记得 defer
file.Close()，否则句柄泄漏
如何边读边计算 SHA256（推荐方式）
用 io.MultiWriter 把上传流同时写入哈希器和（可选）临时文件，避免内存缓冲整个文件。这是 Gin 场景下最稳妥的路径。
示例关键片段：
立即学习“go语言免费学习笔记（深入）”；
file, err := c.FormFile("file")
if err != nil {
c.AbortWithStatusJSON(400, gin.H{"error": "no file provided"})
return
}
src, err := file.Open()
if err != nil {
c.AbortWithStatusJSON(500, gin.H{"error": "failed to open file"})
return
}
defer src.Close()
hash := sha256.New()
// 如果还需保存文件，可加一个 io.Discard 或 os.File 到 multiWriter
if _, err := io.Copy(hash, src); err != nil {
c.AbortWithStatusJSON(500, gin.H{"error": "failed to hash file"})
return
}
c.JSON(200, gin.H{
"sha256": fmt.Sprintf("%x", hash.Sum(nil)),
})
-
io.Copy内部按 32KB 块读取，适合任意大小文件 - 不要用
hash.Write()手动分块——io.Copy更简洁且已优化 - 如果上传字段名不是
"file"，要同步改c.FormFile("xxx")
遇到 multipart boundary 解析失败或空文件怎么办
典型错误信息：http: no such file 或 multipart: NextPart: unexpected EOF，多数因前端未正确设置 enctype="multipart/form-data" 或未绑定 input 的 name 属性。
- Gin 默认只解析前 32MB 的 multipart body，超限会静默截断——可通过
gin.SetMode(gin.ReleaseMode)后调用router.MaxMultipartMemory = 1024 （例如设为 10MB）调整 - 前端 fetch 提交时，必须用
FormData构造，不能 JSON.stringify 后发 - 若用 Postman 测试，确保 Body → form-data → Key 名与后端
c.FormFile("xxx")一致
要不要把文件先保存再算哈希？
不建议。除非业务强依赖文件落盘（比如后续要转码、预览），否则纯校验场景下，边读边哈希更省内存、更快、更可靠。
- 先保存再哈希：需两次磁盘 I/O（写 + 读），并发高时 IO 成瓶颈
- 边读边哈希：一次流式读取，内存占用恒定（≈ 哈希算法内部缓冲区，SHA256 约 128B）
- 如果真要落盘，用
file.SaveToFile("path")之前，先file.Open()算哈希——别依赖保存后的文件重新打开，可能被篡改
散列值本身不解决传输完整性，只是服务端校验起点；若需端到端可信，得配合客户端签名或 TLS+Content-MD5 头。
