推荐使用 io.copy 与 sha256.new() 组合进行流式 gb 级文件校验，避免 os.readfile 导致 oom；需 defer f.close()、每次新建 hasher、检查 io.copy 返回 err、用 hasher.sum(nil) 取结果、bytes.equal 比对、hex.decodestring 处理 http 头哈希、io.sectionreader 安全分段、io.teereader 边传边算，并根据校验目标（传输损坏/篡改/快筛）选择策略。
io.Copy + sha256.New() 是唯一推荐的流式组合
GB 级文件校验不能用 os.ReadFile，它会直接 OOM；必须走流式路径。标准库的 io.Copy 内部已优化缓冲（默认 32KB），与 sha256.New() 组合，全程零手动分块、零额外内存分配，是生产环境事实标准。
-
os.Open()打开文件后务必defer f.Close()，否则句柄泄漏 - 每次校验都新建
sha256.New()实例，复用会导致哈希累加而非重算 -
io.Copy(hasher, f)的返回值err必须检查：磁盘断连、NFS 挂载失效、权限变更都会在这里暴露，不是“算错了”，而是“没读完” - 取结果用
hasher.Sum(nil)，不是hasher.Sum([]byte{})；前者复用内部切片，后者可能触发额外分配
校验失败时先区分是 I/O 错误还是哈希不匹配
日志里只打 "hash mismatch" 是线上排查灾难。真实错误往往藏在 io.Copy 的 err 或 n == 0 里。
-
err != nil：说明读取中途失败，可能是文件被删、磁盘坏道、网络存储掉线 -
n == 0：空文件或os.Open失败后意外进入io.Copy，会产生合法哈希但逻辑异常 - 比对哈希时用
bytes.Equal(sum1[:], sum2[:])，别用字符串==—— 客户端传来的 hex 字符串可能带空格、大小写混用或 padding - 若哈希来自 HTTP header（如
X-Expected-SHA256），必须先hex.DecodeString()并检查 error：非法字符或奇数长度会直接 panic
头尾分段校验要绕过 Seek(io.SeekEnd) 的坑
直接 f.Seek(0, io.SeekEnd) 后读尾部，极易触发 io.EOF 或越界 panic；io.SectionReader 是唯一稳妥方式。
- 头部：用
io.NewSectionReader(f, 0, 64*1024)读前 64KB - 尾部：先
f.Stat()拿Size()，再算偏移max(0, size-64*1024)，传给io.NewSectionReader -
io.SectionReader自动截断超出范围的读取，返回实际字节数 +io.EOF，不会 panic - 若需尾部按行对齐（如日志文件），得倒查
\n或\r\n，最多回溯 4KB，否则可能卡死在超长行
上传场景下必须用 io.TeeReader 边读边算
等文件上传完再算哈希，等于放弃流式优势：内存暴涨、磁盘 IO 冗余、用户等到最后才被告知失败。
-
io.TeeReader(file, hasher)把上传流同时喂给哈希器和落盘写入器，数据只过一遍内存 - 必须确保
hasher.Sum(nil)在io.Copy(dst, teeReader)完成后调用，否则结果不完整 - 若还要限大小，把
teeReader包一层io.LimitReader(teeReader, maxSize) - 分块上传时，MD5(A+B) ≠ MD5(A)+MD5(B)，前端必须计算整体哈希并随首块传
X-Content-MD5，服务端合并后单独校验
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
