应直接流式计算SHA256哈希：调用c.FormFile("file")获取文件头后立即fh.Open()得到io.ReadCloser，用io.Copy配合sha256.New()计算，defer f.Close()防止连接hang住；同时需显式设置engine.MaxMultipartMemory以支持大文件上传。
接收文件时直接计算SHA256，别先保存再读取
多数人会先把 *multipart.FileHeader 保存到磁盘，再用 os.Open 读取计算哈希——这多一次 I/O，还可能因临时文件残留出问题。Gin 的 c.FormFile 返回的文件头本身支持 Open()，拿到的是 io.ReadCloser，可直接流式计算。
关键点：
-
c.FormFile("file")后调用fh.Open()，不是os.Open(fh.Filename) - 务必在计算后调用
defer f.Close()，否则连接可能 hang 住 - 用
io.Copy配合hash.Hash，避免手动分块读取出错
fh, err := c.FormFile("file")
if err != nil {
c.AbortWithStatusJSON(400, gin.H{"error": "no file received"})
return
}
f, err := fh.Open()
if err != nil {
c.AbortWithStatusJSON(500, gin.H{"error": "failed to open file"})
return
}
defer f.Close()
h := sha256.New()
if _, err := io.Copy(h, f); err != nil {
c.AbortWithStatusJSON(500, gin.H{"error": "hash calculation failed"})
return
}
hashStr := hex.EncodeToString(h.Sum(nil))
处理大文件时注意 Gin 的内存限制和超时
Gin 默认不限制表单大小，但实际中若上传几百 MB 文件，c.FormFile 可能卡住或返回 http: request body too large 错误，本质是底层 http.Request 的 MaxMultipartMemory 限制（默认 32MB）。
必须显式配置：
立即学习“go语言免费学习笔记（深入）”；
- 启动前设置
gin.DefaultWriter = os.Stdout不影响，但要改http.Server.MaxHeaderBytes和http.Server.ReadTimeout - 更关键的是：在
gin.Engine初始化后，调用engine.MaxMultipartMemory = 1024 （例如设为 1GB） - 同时确保反向代理（如 Nginx）也放宽
client_max_body_size和proxy_read_timeout
否则你代码逻辑没问题，但请求根本进不到路由函数里，日志只显示 http: request body too large。
校验失败？检查是否误用了 multipart 的 filename 字段
常见错误是把 fh.Filename 当成原始文件名去拼路径，然后 os.Open —— 这不仅绕过流式计算，还会因路径拼接漏洞或空格/中文名导致失败。更隐蔽的问题是：有人拿 fh.Size 做前置判断，但该字段来自 HTTP header，**可被客户端伪造**，不能用于安全校验。
真正可靠的只有：
- 从
fh.Open()得到的io.ReadCloser流本身 - 计算哈希过程中实际读取的字节数（
io.Copy返回值） - 若需比对已知哈希，应在流计算完成后立即比对，不要缓存中间结果
比如传入 expected_hash 查询参数，应这样验证：
expected := c.Query("expected_hash")
if expected != "" && expected != hashStr {
c.AbortWithStatusJSON(400, gin.H{"error": "hash mismatch"})
return
}
并发上传多个文件时，SHA256 计算不能共享 hash 实例
Go 的 hash.Hash 接口实例（如 sha256.New() 返回值）**不是 goroutine 安全的**。如果在同一个 handler 中循环处理多个 FormFile 并复用一个 h 变量，会出现哈希错乱甚至 panic。
正确做法：
- 每个文件单独调用
sha256.New() - 不要试图复用或重置（
h.Reset()在部分实现中不保证线程安全） - 若性能敏感（如每秒上百次小文件），可考虑对象池
sync.Pool，但对 SHA256 来说收益极小，优先保正确性
流式计算本身已足够快，瓶颈通常在磁盘或网络，而非哈希函数。
最易忽略的一点：HTTP 请求体在被 c.FormFile 解析后，整个 body 就被消费掉了。如果之后又调用 c.ShouldBind 或读取 c.Request.Body，会得到空内容——哈希计算必须放在所有其他解析操作之前。
