是的，直接用sha256.sum256处理文件会oom，因其需先将整个文件加载到内存；正确做法是os.open+sha256.new()+io.copy流式计算，内存恒定且错误可检。
直接用 sha256.Sum256 读文件会 OOM？是的，别这么干
很多人看到 sha256.Sum256 这个类型，下意识以为它能“直接哈希文件”，结果写出 sha256.Sum256(fileBytes) ——这其实是把整个文件内容塞进内存再算哈希。对几百 MB 以上的文件，Go runtime 很快报 runtime: out of memory。
sha256.Sum256 是一个 32 字节的结构体，只适合小字节切片（比如配置字符串、短 token），不是为流式输入设计的。它的 Sum 方法返回的是已写入数据的哈希，但你得先调 Write，而不是构造时传参。
- 错误写法：
sum := sha256.Sum256{}; sum.Write(fileBytes); hex.EncodeToString(sum.Sum(nil))——fileBytes已全量加载，没解决内存问题 - 正确路径：放弃一次性读取，改用流式接口
io.Copy + sha256.New() 是唯一推荐组合
io.Copy 内部使用固定大小缓冲区（默认约 32KB），天然适配 hash.Hash 接口，全程不分配额外大块内存。GB 级文件也只占几 KB 堆空间，且代码极简。
关键点不是“能不能用”，而是“怎么链起来不出错”：
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 必须用
os.Open，不是os.ReadFile或ioutil.ReadFile（后者强制加载全文件） -
hasher := sha256.New()每次都要新建实例；复用同一实例会导致哈希值叠加，结果错误 -
io.Copy返回(int64, error)，error必须检查——磁盘掉线、权限变更、NFS 挂载中断都会在这里暴露 -
hash.Sum(nil)才是最终结果；直接打印hasher变量得到的是未完成状态
校验失败不等于文件被篡改，先看这几点
两个文件 SHA256 不一致，90% 的原因和“是否被改”无关，而是流程引入了隐性差异：
- 换行符不一致：Windows 的
\r\n和 Linux 的\n产生不同哈希 - BOM 头：UTF-8 文件开头多了
EF BB BF字节，肉眼不可见但哈希必变 - 符号链接处理：用
os.Lstat获取的是链接自身元信息，os.Open自动解引用，二者哈希对象不同 - 文件末尾空格或不可见控制字符：编辑器自动 trim 或保存策略不同导致
- 挂载参数影响：NFS 或某些容器卷用了
noatime或缓存策略，os.Open读到的是旧缓存数据（极少见但真实存在）
比对哈希值时别用字符串 ==
拿到两个十六进制字符串，直接 hex1 == hex2 看似没问题，但有隐患：
- 若哈希来自 HTTP header（如
X-File-SHA256），可能被注入空格、换行或大小写混用 - 编码过程多一次分配，GC 压力上升，对高频校验服务不利
- 更安全做法：用
hex.DecodeString解码成[]byte，再用bytes.Equal比较原始字节数组 - 注意
hex.DecodeString可能返回 error（长度非偶数、含非法字符），必须检查，否则 panic
真正容易被忽略的，是 f.Close() 的错误检查 —— 它不是可有可无的收尾动作。某些文件系统（尤其是网络存储）在 close 阶段才刷新缓冲、释放锁、校验完整性，出错会晚于 io.Copy，不检查就等于漏掉最后防线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
