应使用 os.open + io.copy + sha256.new() 流式计算哈希，避免 os.readfile 导致 oom；必须检查 io.copy 的 error 和 n 值、hex.decodestring 错误，并用 bytes.equal 比较原始字节数组，每次新建 hasher 实例。
crypto/sha256 是最稳妥的起点，别用 md5 做完整性校验——它只适合内部快速比对，生产环境必须用 sha256。
为什么不能直接 os.ReadFile + sha256.Sum
大文件（比如 500MB 的日志或镜像）会直接 OOM：os.ReadFile 把整个文件塞进内存，而 sha256.Sum 是为小字节切片设计的，不是流式接口。你看到的“能跑通”，只是小文件侥幸没崩。
- 正确路径是：
os.Open打开文件，再通过io.Copy流式写入sha256.New()实例 -
sha256.New()返回的是hash.Hash接口，天然适配流式写入 - 哪怕只有几 KB，也别为了“省事”切到
os.ReadFile+sha256.Sum——代码路径一旦分裂，上线后某天遇到一个 2GB 文件就挂了
io.Copy 的错误和返回值必须显式检查
io.Copy 的第二个返回值 error 容易被忽略，但磁盘突然拔掉、权限变更、NFS 挂载中断时，它会静默截断数据并返回 nil 错误（实际是 io.EOF 或其他底层错误），导致你算出一个“合法但错的”哈希值。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须写成：
n, err := io.Copy(hasher, f) - 若
err != nil，立刻返回带路径的错误，例如fmt.Errorf("read %q: %w", path, err) - 还要检查
n == 0：空文件会生成有效哈希，但业务上往往要拒绝（比如配置文件不能为空）
校验时别用字符串比较，用 bytes.Equal
服务端给的哈希如果是十六进制字符串（如 "a1b2c3"），你得先用 hex.DecodeString 解码成 []byte，再和本地计算出的 hasher.Sum(nil) 结果比对。
- 解码前必须检查
hex.DecodeString的error：长度非偶数、含非法字符（比如空格或换行）都会失败 - 比对时用
bytes.Equal(sum1[:], sum2[:])，不是hex.EncodeToString(sum1[:]) == hex.EncodeToString(sum2[:]) - 前者直接比原始字节数组，零分配、防篡改、抗时序攻击；后者多两次内存分配，且字符串可能被中间人注入空白符
别复用同一个 hasher 实例去算多个文件
结果会串——每次都要新调 sha256.New()。哪怕你 Reset() 了，也容易在并发或 defer 链中漏掉，不如每次新建干净。
-
defer f.Close()要紧挨着os.Open放，别在defer里关文件后还继续用f - 流式路径（
os.Open→io.Copy→hasher.Sum(nil)）对任意大小都恒定内存占用（约 32KB 缓冲区） - 所有错误类型一致：打开失败、读取中断、空文件，都能在同一个
if err != nil分支里处理
io.Copy 返回的 n 值和 hex.DecodeString 的合法性校验——它们不抛 panic，但一旦跳过，校验就形同虚设。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
