生产环境推荐SHA256而非MD5；必须按块流式读取（如io.Copy）避免内存溢出，显式检查错误，哈希比对应使用bytes.Equal或subtle.ConstantTimeCompare，摘要文件须分离存储且来源可信。
用 crypto/md5 或 crypto/sha256 计算文件哈希值
读取文件完整性校验，本质是比对「预期哈希」和「实际读取后计算的哈希」是否一致。Go 标准库的 crypto/md5 和 crypto/sha256 是最常用选择，sha256 更推荐（MD5 已不安全，仅用于兼容旧系统）。
关键点不是“能不能算”，而是“怎么算才不崩、不慢、不漏”：
- 不要用
ioutil.ReadFile或os.ReadFile一次性加载整个文件——大文件（如 >100MB）会吃光内存 - 必须用
io.Copy配合hash.Hash的io.Writer接口流式计算，边读边哈希 - 注意打开文件后务必调用
file.Close()，否则可能触发“too many open files”错误
func fileHash(path string) ([32]byte, error) {
f, err := os.Open(path)
if err != nil {
return [32]byte{}, err
}
defer f.Close()
h := sha256.New()
if _, err := io.Copy(h, f); err != nil {
return [32]byte{}, err
}
return h.Sum([32]byte{}), nil
}
校验时遇到 EOF 或 unexpected EOF 怎么办
这类错误通常不是哈希逻辑出错，而是文件读取中途被截断或损坏——比如文件正在被另一个进程写入、磁盘突然满、NFS 挂载异常断连。
此时 io.Copy 会返回非 nil 错误，h.Sum() 得到的哈希值无效，不能继续比对：
立即学习“go语言免费学习笔记（深入）”；
-
EOF：正常结束，但只在你明确知道文件该读完时才算“正常”；若预期长度已知，应提前校验字节数是否匹配 -
unexpected EOF：典型读取中断，直接判定校验失败，不要尝试“忽略并继续” - 建议在哈希前先用
f.Stat()获取文件大小，与预期 size 对比，快速排除明显缺失
如何安全比对两个哈希值（避免时序攻击）
如果校验目标是用户可控输入（如 HTTP 请求里传来的期望哈希），直接用 == 比较 []byte 有被时序攻击利用的风险——攻击者可通过响应时间差异推断哈希前缀。
标准解法是用 crypto/subtle.ConstantTimeCompare：
- 它强制逐字节比较完整长度，不提前退出
- 只接受
[]byte，所以要把[32]byte转成切片：bytes.Equal(h1[:], h2[:])不安全，subtle.ConstantTimeCompare(h1[:], h2[:]) == 1才安全 - 注意：该函数返回
int，不是bool，别写成if subtle.ConstantTimeCompare(...) { ... }
需要支持分块校验或断点续校验怎么办
纯哈希无法满足分块场景（比如下载器校验每一段、云存储多段上传后合并校验）。这时得换思路：
- 用
sha256.Write()分多次调用，只要哈希对象未重置，结果等价于一次写入全部数据 - 若需“已读前 N 字节的中间哈希”，可保存
h.Sum(nil)快照，但注意hash.Hash不支持回滚，只能重新初始化再重放前面的数据 - 真正高效的分块校验（如 torrent 的 piece hash）需预定义块大小，并为每块单独计算哈希，最后再组合（例如 Merkle 树），这已超出单文件完整性范畴，别硬套
io.Copy + hash
流式哈希本身不记录进度，所谓“续校验”必须靠外部维护已读偏移量，并从对应位置 file.Seek() 后继续 io.Copy ——但要注意 Seek 可能失败（如管道、socket 不支持随机访问）。
