最可靠路径是直接用 crypto/sha256 流式计算 + io.Copy，但须绕开 os.ReadFile、复用哈希器、字符串比对三类坑：每次校验前调用 sha256.New()，并发下严禁共享实例；io.Copy 必检查返回值和错误；哈希比对必须用 bytes.Equal 而非字符串 ==；大文件需复用固定大小缓冲区。
直接用 crypto/sha256 流式计算 + io.Copy 是最可靠路径，但必须绕开 os.ReadFile、重复复用哈希器、字符串比对这三类坑，否则校验结果不可信。
为什么 crypto/sha256.New() 必须每次新建
哈希器不是纯函数，内部状态可变。复用同一个 sha256.Hash 实例连续计算两个文件，第二个结果会叠加第一个的残留状态，导致哈希值错误。并发场景下更危险：多个 goroutine 写入同一实例，结果彻底不可预测。
- 每个文件校验前都调用
sha256.New()，不要缓存或全局复用 - 若需高频调用（如每秒百次），可用
sync.Pool管理，但必须保证pool.Put()前重置状态（hash.Reset()） - 别用
sha256.Sum256{}零值结构体——它没写入任何数据，Sum(nil)返回空哈希
io.Copy 必须检查返回值和错误
io.Copy 返回实际复制字节数和错误，忽略任一者都会掩盖真实问题：磁盘满、权限不足、文件被其他进程锁定、甚至 NFS 挂载突然断开，都可能让 io.Copy 提前终止，但哈希仍能算出“有效”值。
- 显式检查
err != nil，并带上文件路径构造错误信息，例如fmt.Errorf("read %s: %w", path, err) - 检查
n == 0，空文件应单独拒绝，而非返回一个确定哈希值 - 不要只靠
hash.Sum(nil)是否 panic 来判断成功——它从不 panic，只默默返回错误结果
比对哈希必须用 bytes.Equal，不能用字符串 ==
十六进制字符串比较看似简单，但存在时序攻击风险（虽在文件校验中影响有限）、编码歧义（大小写、空格、换行）、以及 GC 开销。更重要的是，服务端接收的哈希值常来自 HTTP Header 或 JSON，可能被篡改或截断。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 本地计算结果保留为
[]byte，例如sum := h.Sum(nil) - 远端传来的哈希先用
hex.DecodeString解码成[]byte，必须检查解码错误 - 最终比对统一用
bytes.Equal(localSum[:], remoteSum[:]) - 若需日志输出，再用
hex.EncodeToString转字符串，但绝不参与逻辑判断
大文件分块读取的缓冲区要固定且复用
频繁 make([]byte, 0, 32*1024) 会触发小对象 GC；而 make([]byte, 32*1024) 分配固定大小切片更省内存。但真正关键的是：缓冲区必须复用，否则每读一块就 new 一次，大文件校验会额外分配数 MB 内存。
- 定义全局缓冲区变量：
var buf = make([]byte, 32*1024) - 在循环中直接传给
file.Read(buf)，避免切片扩容 - 注意
file.Read可能返回n ，需用 <code>n作为实际写入长度传给hash.Write(buf[:n]) - 不用
io.Copy时，务必手动处理 EOF 和 partial read
真正难的不是算哈希，而是确保「从打开文件那一刻起，到哈希输出为止」整个链路没有一处跳过错误检查、没有一次指针偏移错位、也没有一个字节被悄悄丢弃——这些细节全在 io 和 os 的返回值里藏着。
