不能复用同一个 hash.Hash 实例校验多个文件，因为其状态不可重置，第二个文件哈希实为两文件拼接结果；正确做法是每个文件单独调用 md5.New() 或 sha256.New()。
为什么不能复用同一个 hash.Hash 实例校验多个文件
复用 md5.New() 或 sha256.New() 返回的实例去算多个文件，第二个文件的哈希值其实是第一个 + 第二个文件内容拼接后的结果——看着没报错，但值完全错。这是因为 hash.Hash 接口既不是并发安全的，也不支持重置状态；Sum(nil) 只读取当前累积状态，不清理内部缓冲。
- 错误写法：
h := md5.New()放在循环外，然后反复io.Copy(h, f) - 正确做法：每个文件都调一次
md5.New()或sha256.New() - 别依赖未公开的
Reset()方法——hash.Hash接口没定义它，md5.digest.Reset()是内部实现，不保证稳定 - 并发场景下更要严格隔离：每个 goroutine 自己
new、自己Open、自己Copy
io.Copy 是唯一推荐的流式计算方式
手动分块 Read + Write 容易漏数据、忽略错误、多分配内存；io.Copy 内置 32KB 缓冲区，对 hash.Hash 做了零拷贝路径优化，且自动处理 io.EOF 和真实错误的区别。
- 错误写法：
for { n, _ := file.Read(buf); h.Write(buf[:n]); if n == 0 { break } }—— 没检查err，也没区分io.EOF和磁盘损坏 - 正确写法：
n, err := io.Copy(h, file)，必须检查err != nil，也要判断n == 0（空文件） - 别用
os.ReadFile：大文件直接 OOM，哪怕只是 200MB 的 zip，在容器里也可能被 kill - 加
bufio.NewReader(f)对机械盘小文件有收益，SSD 上无害但没必要
比对哈希值时最容易忽略的三个细节
哈希校验失败，90% 不是算法问题，而是比对环节出错：字符串 vs 字节、大小写、编码格式混用。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 服务端给的哈希如果是 hex 字符串（如
"a4f87b2c"），必须先用hex.DecodeString解码成[]byte，再和本地h.Sum(nil)[:]比较 - 绝对不要用
==直接比两个[]byte，用bytes.Equal(a, b)防时序攻击 - 如果对方提供的是 base64（比如 HTTP
Digest头），要用base64.StdEncoding.DecodeString，不是hex - 提前用
strings.TrimSpace清掉两端空白，用strings.ToLower统一小写——避免因换行、空格、大小写导致误判
空文件和错误处理必须显式覆盖
空文件会生成确定哈希（SHA256 是 e3b0c442...），但业务上往往不该让它通过校验。I/O 错误若不检查，就会拿部分数据算出“有效哈希”，掩盖真实问题。
立即学习“go语言免费学习笔记（深入）”；
- 算哈希前先
stat, _ := os.Stat(path)，if stat.Size() == 0就提前返回错误 -
io.Copy的err必须检查：权限不足、磁盘满、fuse 中断都会在这里暴露 - 打开文件后立刻
defer file.Close()，否则 fd 泄漏在长期服务中会触发too many open files - 错误信息里带操作动词和路径，例如
return "", fmt.Errorf("read %s: %w", path, err)，方便日志归因
io.Copy(h, file)，而是确保每次新建哈希实例、每次都检查 err、每个比对都走 bytes.Equal 而不是字符串相等——这些点散落在不同层级，容易只顾一头。 
