os.ReadFile会导致大文件校验崩溃，因为它一次性将整个文件加载进内存，GB级文件直接触发OOM；正确做法是用os.Open+io.Copy流式处理，内存占用恒定约32KB，且需每次新建sha256.New()实例、defer关闭文件句柄、用bytes.Equal安全比对哈希值。
为什么 os.ReadFile 会导致大文件校验崩溃
os.ReadFile 会把整个文件一次性加载进内存，对 GB 级文件就是直接 OOM。这不是“可能慢”，是必然失败。真正该用的是 os.Open 配合 io.Copy 流式处理——它默认用 32KB 缓冲区分块读，内存占用恒定在几 KB，和文件大小无关。
- 别写
data, _ := os.ReadFile("big.zip"); h.Write(data) - 正确路径是：
f, err := os.Open("big.zip")→io.Copy(h, f) - 必须
defer f.Close()，否则并发扫描几十次后触发too many open files -
io.Copy返回实际读取字节数，可用于校验是否完整（比如对比f.Stat().Size()）
sha256.New() 和 sha256.Sum256{} 完全不是一回事
sha256.Sum256{} 是个 32 字节的值类型结构体，Sum(nil) 返回的是它内部缓存的哈希值——但如果你没往里写过任何数据，它就只是全零。很多人误写成 sha256.Sum256(fileBytes)，这等价于先 os.ReadFile 再构造结构体，照样爆内存。
-
sha256.New()才是流式哈希器，实现了io.Writer，能接io.Copy - 每个文件都必须调用一次
sha256.New()，复用同一个实例会导致哈希累加（A+B 的哈希 ≠ B 的哈希） - 并发场景下，每个 goroutine 必须持有独立的
hash.Hash实例，它不线程安全 - 别用
fmt.Sprintf("%x", sum)打印sha256.Sum256，那打印的是字段地址，不是哈希值
校验比对时字符串比较是危险的
服务端传来的X-File-SHA256 头可能是小写、大写、带空格、换行，甚至多了前缀 sha256:。直接用字符串 == 比对，很容易漏掉这些差异；更严重的是，如果哈希来自用户输入，还可能被时序攻击利用。
- 先用
hex.DecodeString(strings.TrimSpace(headerValue))解码成[]byte，检查err - 本地计算完用
h.Sum(nil)[:]取原始字节数组 - 用
bytes.Equal(localHash, remoteHash)比对，不是==，也不是strings.EqualFold - 如果对方给的是 base64（如 CSP header），要用
base64.StdEncoding.DecodeString，不是 hex
空文件、EOF 和 unexpected EOF 怎么处理
io.Copy 返回 unexpected EOF 不代表哈希算错了，而是文件读取中途中断——可能是磁盘满、NFS 断连、文件正被其他进程写入。此时 h.Sum(nil) 得到的哈希无效，不能继续比对。
- 算哈希前先
os.Stat()拿 size，为 0 就提前返回错误，别浪费 CPU -
io.Copy出错时，错误信息里带上文件路径，方便日志定位：fmt.Errorf("read %s: %w", path, err) -
EOF要区分场景：如果是预期结尾（比如已知 size），可接受；否则要报警 -
f.Close()也必须检查错误——某些文件系统（如 fuse 或 NFS）会在 close 阶段才暴露写入失败
真实世界里，校验失败往往不是算法问题，而是路径权限、符号链接未解引用、换行符差异或 BOM 头这些细节没控住。哈希本身很稳，出问题的地方永远在边界。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
