md5.Sum不能用于大文件秒传校验，因其返回固定数组且不支持增量计算；应使用md5.New()返回的hash.Hash接口配合io.TeeReader流式计算MD5。
为什么 md5.Sum 不能直接用于大文件秒传校验
因为 md5.Sum 返回的是固定大小的数组（[16]byte），不是可比较的 []byte；更关键的是，它没法增量计算——你不能边读文件边更新哈希值，必须把整个文件加载进内存才能算。这对几百 MB 的上传文件来说，等于直接 OOM。
- 真正该用的是
md5.New()返回的hash.Hash接口，支持Write()流式写入 - 别对
*os.File直接调md5.Sum()，那是对底层字节切片求和，不是对文件内容 - HTTP 请求体里的文件流（比如
multipart.File）无法 rewind，必须在读取上传数据的同时计算 MD5，否则就得临时存盘再算一遍——那就失去“秒传”意义了
如何在不保存临时文件的前提下完成流式 MD5 计算
核心思路：用 io.TeeReader 把上传流“分叉”——一份送给存储逻辑（如写入磁盘或对象存储），另一份实时喂给 md5.Hash。
- 先创建
hash := md5.New() - 构造
teeReader := io.TeeReader(filePart, hash)，其中filePart是从multipart.Reader解析出的io.Reader - 后续所有读操作（比如
io.Copy(dst, teeReader)）都会同步更新hash - 读完后调
hash.Sum(nil)得到[]byte，再用hex.EncodeToString()转成标准 MD5 字符串
注意：io.TeeReader 不会缓冲，也不改变原流行为，但要求下游 reader 必须完整读完，否则 MD5 不完整。
前端传来的 MD5 字段怎么安全校验
不能直接信任前端提交的 Content-MD5 或自定义字段，必须和服务端计算结果严格比对。常见翻车点是大小写和编码格式不一致。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 前端通常用
ArrayBuffer+crypto.subtle.digest算出 ArrayBuffer，再转成十六进制字符串——默认小写 - Go 侧用
hex.EncodeToString(hash.Sum(nil))也是小写，可以直接==比较 - 如果前端用了 Base64 编码（比如 HTTP 标准
Content-MD5头），服务端就得用base64.StdEncoding.DecodeString()先解码，再和hash.Sum(nil)比bytes.Equal() - 字段名建议统一用
X-File-Md5，避开某些代理对标准头的自动处理
秒传判定后跳过上传，但要注意文件内容一致性
MD5 相同只代表二进制一致，不代表业务上可以无条件跳过。比如用户重复上传同一张图，但元数据（如 EXIF 时间、文件名）不同，是否要覆盖原记录？这个逻辑不在哈希层，而在业务层。
- 不要仅靠 MD5 做去重索引，建议把 MD5 作为主键之一存进数据库，同时带上原始文件名、上传时间、用户 ID 等上下文
- 如果允许秒传，返回的响应里必须明确告知客户端：“已存在，跳过上传”，并附带已有资源的 URL 或 ID
- MD5 碰撞概率虽低，但在可信内网场景下可接受；若面向公网且对安全性敏感，应升级为 SHA256，并注意
sha256.New()同样要走流式路径
最易被忽略的一点：HTTP multipart 解析失败时，filePart 可能是 nil 或空 reader，此时 hash.Sum(nil) 会返回全零 MD5 —— 务必在计算前加非空检查，否则所有坏请求都“命中”同一个假缓存。
