生产环境推荐SHA256而非MD5进行文件完整性校验；须按块读取避免内存溢出，显式检查io.Copy错误，哈希比对直接用==即可，摘要文件应分离存储并确保来源可信。
用 crypto/md5 或 crypto/sha256 计算文件哈希值
Go 标准库直接支持常见哈希算法，无需第三方依赖。关键不是“选哪个算法”，而是根据校验目的决定：MD5 仅适合内部快速比对（如构建缓存），SHA256 才是生产环境推荐的完整性校验标准。
计算时必须按块读取（不能 os.ReadFile 全量加载），否则大文件会爆内存：
func fileHash(path string, h hash.Hash) (string, error) {
f, err := os.Open(path)
if err != nil {
return "", err
}
defer f.Close()
if _, err := io.Copy(h, f); err != nil {
return "", err
}
return hex.EncodeToString(h.Sum(nil)), nil
}
// 使用示例
sha256sum, _ := fileHash("data.bin", sha256.New())
- 必须传入新实例（如
sha256.New()），重复使用同一hash.Hash实例会导致结果错误 - 别用
md5.Sum([]byte)直接处理文件内容——那是为小字节切片设计的，不适用于文件流 - 如果校验对象是网络响应体或管道数据，同样适用
io.Copy+hash.Hash模式
校验失败时如何定位是读取错误还是哈希不匹配
哈希计算过程本身不会“静默失败”，但底层 Read 错误可能被 io.Copy 吞掉（比如磁盘突然断开、权限变化）。必须显式检查返回值：
n, err := io.Copy(h, f)
if err != nil {
return "", fmt.Errorf("read %s: %w", path, err) // 明确区分 I/O 错误
}
if n == 0 {
return "", fmt.Errorf("empty file %s", path) // 防止空文件产生有效哈希却逻辑异常
}
- 错误信息里带原始路径和操作动词（如
read），方便日志中快速归因 - 不要只对比哈希字符串相等就认为“校验通过”——先确保
err == nil且n > 0 - 若需同时校验多个文件，建议每个文件单独打开/关闭，避免单个失败影响后续
如何安全比对两个哈希值（防止时序攻击）
用 bytes.Equal 或 crypto/subtle.ConstantTimeCompare？答案是：普通文件校验完全不需要防时序攻击。
立即学习“go语言免费学习笔记（深入）”；
只有当你在 HTTP 接口里直接比对用户提交的哈希与服务端预存哈希时，才需防御——而这种情况本身就不该暴露原始哈希比对逻辑。文件完整性校验属于离线、可信上下文，直接用 == 即可：
if computed == expected {
log.Println("integrity OK")
} else {
log.Printf("mismatch: got %s, want %s", computed, expected)
}
-
subtle.ConstantTimeCompare要求输入是[]byte，且长度必须一致；哈希字符串长度固定（如 SHA256 是 64 字符），但额外做 base64/hex 编码转换反而增加出错点 - 真正该花精力的地方是：确保
expected哈希来源可信（如签名过的 manifest 文件），而不是纠结字符串比较方式
把哈希写入文件末尾或独立 .sha256 文件的取舍
追加到原文件末尾看似省事，实际破坏原始二进制结构，导致很多工具（如 tar、gzip）无法正确解析。标准做法是生成分离的摘要文件：
- 同名 + 后缀：
archive.tar.gz.sha256，内容为abc123... archive.tar.gz（符合 GNU coreutilssha256sum格式） - 用
os.WriteFile写摘要文件时，务必加0644权限，避免因 umask 导致不可读 - 若需验证，用
sha256sum -c archive.tar.gz.sha256可直接复用系统工具，不必重写逻辑
最易被忽略的一点：校验前必须确认摘要文件自身未被篡改——它应该和原始文件一起被数字签名，或从可信源单独下载。否则攻击者完全可以同步替换文件和它的哈希值。
