直接用sha256.Sum256计算大文件会爆内存，因其非流式哈希器，误用fileBytes参数需先加载全文件到内存；安全方式是os.Open+sha256.New()+io.Copy流式处理，内存恒定且需检查io.Copy和Close错误。
为什么直接用 sha256.Sum256 读完整个文件会爆内存
因为 sha256.Sum256 是一个固定大小的结构体（32 字节），但很多人误以为它能“直接哈希大文件”，结果写成 sha256.Sum256(fileBytes) —— 这其实是把整个文件读进内存再算，对 GB 级文件立刻 OOM。
真正该用的是流式哈希：hash.Hash 接口 + io.Copy 或分块 Write。
如何安全地计算大文件的 SHA256 值（带错误处理）
核心是用 sha256.New() 创建哈希器，然后通过 io.Copy 把文件流喂给它。这样内存占用恒定（约几 KB），与文件大小无关。
实操建议：
- 始终用
os.Open打开文件，不是ioutil.ReadFile或os.ReadFile - 哈希计算后必须调用
hash.Sum(nil)获取结果，不能直接打印hash变量 - 记得关闭文件句柄，用
defer f.Close()，否则小文件可能不显问题，大文件并发时易触发 “too many open files” - 错误检查不能只看
io.Copy，还要检查f.Close()—— 文件系统在 close 阶段才真正刷盘或释放锁，出错可能晚于读取
示例片段：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
f, err := os.Open("archive.zip")
if err != nil {
return "", err
}
defer f.Close()
h := sha256.New()
if _, err := io.Copy(h, f); err != nil {
return "", err
}
// 注意：Sum 返回 []byte，需要 hex.EncodeToString 转成字符串
return hex.EncodeToString(h.Sum(nil)), nil
校验时比对失败的常见原因（不只是内容不同）
SHA256 值不一致，90% 不是因为文件被篡改，而是校验流程本身引入了差异：
- 源文件和目标文件的换行符不一致（比如 Windows 写的文本被 Linux 工具重写过）
- 文件末尾多了空格、BOM（尤其是 UTF-8 BOM：
EF BB BF） - 使用了不同的打开模式：一个用了
os.O_RDONLY | os.O_SYNC，另一个没加O_SYNC，导致缓存未刷新就哈希（极少见，但 NFS 或某些容器挂载场景下会发生） - 校验程序读取了符号链接本身（
lstat），而不是它指向的文件内容 —— 应统一用os.Open，它自动解引用
要不要加 salt？SHA256 本身是否防碰撞
单纯做完整性校验（比如下载后验证 zip 是否损坏），不需要 salt。SHA256 输出是确定性的：相同输入永远得相同输出，这正是校验所需的基础特性。
加 salt 是为了对抗彩虹表或防止批量预计算，属于密码学场景（如密码哈希），和文件完整性无关。反而加 salt 会让校验方无法复现哈希值 —— 除非 salt 也公开，那就失去意义。
注意：SHA256 目前没有已知可行的碰撞攻击（即找到两个不同输入产生相同输出），但理论碰撞复杂度是 2¹²⁸；只要文件不是被针对性构造的恶意输入，可认为安全。日常校验中，更大概率出问题是 I/O 错误或路径搞错，而不是哈希算法失效。
