不能用os.ReadFile计算大文件哈希，因其会一次性将整个文件加载进内存导致OOM或卡死；正确做法是os.Open+sha256.New()+io.Copy流式处理，内存恒定、错误可检、需defer关闭文件并用hex.EncodeToString转哈希字符串。
为什么不能用 os.ReadFile 计算大文件哈希
直接用 os.ReadFile 读取文件再喂给哈希器，等于把整个文件塞进内存——2GB 的 ISO 文件会让进程 OOM 或卡死。这不是性能问题，是内存模型硬伤。
-
os.ReadFile("big.zip")返回[]byte，哪怕只调一次h.Write(data)，也已全量加载 -
io.Copy(h, file)是流式分块（默认 32KB 缓冲），内存占用恒定，且自动传播Read错误 - 漏掉
defer file.Close()会导致 fd 泄露，Linux 默认上限 1024，很快报too many open files
如何正确调用 crypto/sha256.New() 做流式计算
别复用同一个 hash.Hash 实例，也别用 sha256.Sum256{} 零值结构体——它不实现 io.Writer，也不会随 Sum(nil) 重置状态。
- 每次校验必须新建：用
sha256.New()，不是sha256.Sum256{} -
io.Copy(h, file)后，用h.Sum(nil)获取结果，不是fmt.Sprintf("%x", h)（后者打印的是接口地址） - 转十六进制字符串必须用
hex.EncodeToString(h.Sum(nil))，否则 panic 或返回空字符串 - 若需比对原始字节（如校验 HTTP
SHA256头），直接用bytes.Equal(sum1[:], sum2[:])，别转字符串再比
校验失败时怎么快速定位是读错还是哈希错
io.Copy 返回的 n, err 是唯一可信信号。静默失败往往来自底层 I/O 中断，比如磁盘拔出、权限变更或 NFS 挂载失效。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须显式检查
err != nil，并带上路径上下文：fmt.Errorf("read %s: %w", path, err) -
n == 0且err == nil表示空文件，业务上常需单独处理（如拒绝上传或打日志告警） - 别在
err == nil后就直接比哈希字符串——先确认n > 0，否则空文件会产出有效哈希却掩盖逻辑缺陷 - 对方给的哈希若带前缀（如
sha256:abc...）、换行或空格，要用strings.TrimSpace()和strings.ToLower()标准化后再解码
MD5 还能用吗？什么时候该切到 SHA256
MD5 不是“不能用”，而是适用场景极其有限：内部可信路径下的缓存键生成或日志归档去重可以，但凡涉及用户输入、外部对接或长期存档，必须换 SHA256。
立即学习“go语言免费学习笔记（深入）”；
- MD5 碰撞已被实证攻破，
sha256.Sum256抗碰撞性强得多，标准库无兼容风险 - 实测 1GB 文件，MD5 比 SHA256 快约 1.8 倍，但吞吐优势在 SSD + goroutine 并发下几乎不可见
- 别用
sha1：Go 文档明确标注insecure，且被主流 CA 停用多年 - 哈希值存储格式要一致——数据库存
hex.EncodeToString(sum[:])，文件系统分层建目录用sum[0:2]和sum[2:]，两处编码逻辑差一点就查不到
sha256.New() 这一行代码，而是文件是否被并发修改、符号链接是否解析、空文件怎么归一化、哈希值在不同层之间怎么映射——这些地方不出错则已，一错就是静默失效。 
