io.copy + hash.hash 是唯一靠谱路径，因 os.readfile 会全量加载文件致oom，而 io.copy 恒定内存；须每次新建 hash 实例或显式 reset；比对用 bytes.equal，校验前清理输入；生产用 sha256。
io.Copy + hash.Hash 是唯一靠谱的路径，别碰 os.ReadFile 或 md5.Sum——大文件直接 OOM，小文件也埋下复用隐患。
为什么不能用 os.ReadFile 计算文件哈希
它会把整个文件一次性加载进内存。一个 1.2GB 的日志压缩包，os.ReadFile 可能吃掉 1.2GB 堆内存，触发 GC 频繁或被系统 OOM kill；而 io.Copy 默认使用约 32KB 缓冲区，内存占用恒定，与文件大小无关。
- 错误写法：
data, _ := os.ReadFile("big.tar.gz"); h.Write(data) - 正确路径：
f, _ := os.Open("big.tar.gz"); io.Copy(h, f) - 漏掉
defer f.Close()会导致 fd 泄露，Linux 默认最多 1024 个打开文件，后续os.Open会直接返回too many open files
sha256.New() 必须每次新建，不能复用同一实例
复用未重置的 hash.Hash 实例，第二个文件的哈希值其实是“第一个 + 第二个”内容拼接后的结果。Go 的哈希器不是线程安全的，且 Sum(nil) 不会清空内部状态。
- 错误写法：
h := sha256.New(); io.Copy(h, f1); io.Copy(h, f2)→f2结果错误 - 正确做法：每个文件都走完整流程 ——
os.Open→ 新建h := sha256.New()→io.Copy→h.Sum(nil) - 高频小文件场景（如校验上千个 config 文件）可复用，但必须显式调用
h.Reset()，且确保单 goroutine 独占该实例
比对哈希值时，别用字符串 ==，优先用 bytes.Equal
字符串比较看似简单，但存在两个风险：一是十六进制编码过程引入额外分配和 GC 开销；二是不可信来源（如 HTTP 响应头）可能带空格、换行或大小写混杂，导致误判。
- 服务端返回的哈希常带前缀，比如
SHA256: ab12...cd，需先strings.TrimSpace+strings.TrimPrefix清理 - 若对方提供的是 base64 编码（如
digest头），必须用base64.StdEncoding.DecodeString解码成[]byte，再跟本地hasher.Sum(nil)比较 - 解码失败（如长度非偶数、含非法字符）会返回 error，必须检查，不能忽略
- 最终比对统一走
bytes.Equal(sum1[:], sum2[:])，安全且零分配
生产环境默认选 crypto/sha256，不是 MD5
MD5 已不满足抗碰撞要求，仅适合构建缓存等非安全场景；SHA256 是当前完整性校验的事实标准，标准库支持成熟，性能足够好。
-
crypto/sha512输出 64 字节，比 SHA256 的 32 字节多一倍存储/传输开销，实测在多数 I/O 场景下反而慢 10%–20% - 替换算法只需改 import 和构造函数名（
sha256.New()→sha512.New()），逻辑无变化，但字段长度、数据库 schema、HTTP 头都要同步调整 - 摘要文件（如
checksums.sha256）必须分离存储，并确保其本身来源可信——否则校验失去意义
Read 错误可能被 io.Copy 吞掉。必须显式检查 io.Copy 返回的 err，并区分是 I/O 故障（磁盘断开、权限变更）还是内容为空（n == 0）。定位问题时，错误信息里带原始路径和动词（如 "read /data/file.zip"）才能快速归因。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
