用sha256.New()流式计算文件哈希才是正解，需os.Open→sha256.New()→io.Copy三步完成，自动分块、不OOM、必须检查err并defer Close。
用 sha256.New() 流式计算文件哈希才是正解
别用 os.ReadFile() 读大文件再哈希——几百 MB 就可能 OOM，GB 级直接卡死或被系统 kill。Go 标准库没提供 sha256.File() 这种“捷径”，必须自己搭流水线。
核心逻辑就三步：os.Open 打开句柄 → sha256.New() 创建哈希器 → io.Copy 把文件流写进去。它自动分块（默认 32KB），不占额外内存，还顺带处理了读错误。
-
io.Copy返回值必须检查：磁盘满、权限不足、网络文件中断都会在这里报错，忽略等于埋雷 - 记得
defer file.Close()，否则 fd 泄露，跑久了会报too many open files - 机械硬盘上可加
bufio.NewReader(file)包一层，小块读取更稳；SSD 上收益不大，可省
Sum(nil) 和 Sum256() 别混用，返回值类型完全不同
sha256.Sum256(data) 返回的是一个固定大小的结构体 [32]byte，而 sha256.New().Sum(nil) 返回的是动态切片 []byte。两者不能赋值给同一个变量，也不能传给期望 hash.Hash 接口的函数。
- 对字符串一次性哈希，优先用
sha256.Sum256([]byte(s))：零分配、快、代码短 - 对文件或需要多次
Write()的场景，必须用sha256.New()+Write()/io.Copy() -
Sum(nil)中的nil表示“不复用已有底层数组”，安全但略慢；若高频计算，可预分配make([]byte, 0, sha256.Size)传进去
输出哈希字符串时，fmt.Sprintf("%x", h.Sum(nil)) 比 hex.EncodeToString() 更轻量
两种方式都能转小写十六进制，但 fmt.Sprintf("%x", ...) 不依赖 encoding/hex 包，代码更干净，性能也略优（尤其短字符串）。只要你的哈希器实现了 hash.Hash 接口，Sum(nil) 返回的 []byte 就能直接喂给 %x。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 别写
fmt.Println(h.Sum(nil))：输出是{[123 45 67 ...]}这种结构体字面量，不是你要的哈希串 - 也别写
hex.EncodeToString(h.Sum(nil)[:])：多此一举，h.Sum(nil)已是切片，[:]是冗余操作 - 如果后续要 Base64 编码（比如存密码），才需要
encoding/base64，此时必须用h.Sum(nil)或Sum256().[:]
校验场景下，SHA256 是默认选择，MD5 已不该出现在新代码里
除非对接老旧协议（比如某些 CDN 的 ETag），否则别碰 MD5。它已被实证可构造碰撞，连下载包完整性校验都不可信。SHA256 是当前 Go 标准库中平衡安全性、性能与兼容性的最优解。
- 校验两个文件是否一致？分别算 SHA256 字符串再
==比较，比bytes.Equal文件内容快几个数量级 - 需要同时算多个哈希（如 MD5 + SHA256）？用
io.MultiWriter(md5Hash, sha256Hash)，一次读取、双路写入 - 硬编码预期哈希值时，用小写十六进制（
%x输出格式），避免大小写比对失败
最容易被忽略的其实是错误处理和资源释放：每个 os.Open 都得配 defer Close，每个 io.Copy 都得检查 err。这些不是“锦上添花”，而是文件哈希在生产环境能稳定跑下去的底线。
