sha256.New()是唯一安全起点，因sha256.Sum256不支持流式计算且隐式调用os.ReadFile会导致OOM；正确做法是os.Open+io.Copy流式写入sha256.New()返回的hash.Hash接口。
sha256.New() 是唯一安全起点，直接用 sha256.Sum256 或 os.ReadFile 读大文件必然 OOM —— 内存占用和文件大小成正比，不是“可能爆”，是“一定爆”。
为什么 sha256.Sum256(fileBytes) 是错的
这不是调用方式问题，是语义误解：sha256.Sum256 是一个固定 32 字节的结构体，它的零值方法（如 sum.Sum(nil)）不接收输入，也不读文件；所谓“传入 fileBytes”其实是 Go 的隐式转换语法糖，等价于先 os.ReadFile 把整个文件加载进内存，再构造临时切片喂给哈希器。GB 级文件会立刻触发 runtime OOM。
- 正确路径只有一条：用
os.Open打开文件句柄，再通过流式接口写入 -
sha256.Sum256{}初始化后直接调Sum(nil)，返回的是空哈希（32 个 0x00），不是文件哈希 - 若真要小文件快速哈希（h.Write(buf)，而非依赖 Sum256 的语法糖
io.Copy 流式计算必须检查两个错误
常见写法只判 io.Copy 返回的 err，但漏掉更关键的一环：f.Close() 也可能失败。尤其在 NFS、容器挂载卷或磁盘满时，close 阶段才真正刷新缓存或释放锁，错误会延迟暴露。
- 必须显式检查
f.Close()错误，不能只靠defer f.Close() -
io.Copy返回的n, err中，err == nil不代表读完——需结合os.Stat().Size()校验是否读取字节数匹配 - 如果文件被其他进程截断或修改，
io.Copy可能提前 EOF，但不报错；此时哈希值无效
校验比对别用字符串，用原始字节
服务端提供哈希字符串（如 HTTP 响应头里的 SHA256: a1b2c3...），客户端解码后得到 []byte；本地算出的 hash.Sum(nil) 也是 []byte。二者应直接用 bytes.Equal 比较，而不是转成 hex 字符串再 ==。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
hex.EncodeToString引入额外内存分配和 GC 压力，对高频校验场景明显拖慢 - 十六进制字符串可能被中间人注入空格、换行或大小写混用；
hex.DecodeString虽不区分大小写，但非法字符（如 'g'）会直接返回 error，必须检查 - 数据库存哈希时，字段类型必须是
BINARY(32)，不是VARCHAR(64)；否则索引失效，查重变全表扫描
多文件/分片场景下哈希顺序不能错
用 io.MultiReader 合并多个 *os.File 计算整体哈希时，文件顺序就是哈希输入顺序。A+B 和 B+A 的哈希值完全不同，且无任何提示。
立即学习“go语言免费学习笔记（深入）”；
- 文件列表必须严格排序（如按绝对路径字典序），不能依赖
filepath.Walk的遍历顺序——它受文件系统实现影响 - 分片上传中，每个分片单独哈希再拼接，和整体哈希不等价；必须用
MultiReader或边上传边TeeReader流式计算 - 符号链接需统一用
os.Open（自动解引用），避免os.Lstat读到链接自身内容导致哈希不一致
